I've recently converted gnome-power-manager to DeviceKit-power. The
amount of code I've deleted is simply staggering, and apart from a few
typos it seems to have gone down quietly with users.

One feature I've yet to convert is cell phones, where the data is
presented from gnome-phone-manager (session).

In the old g-p-m model we had this, where g-p-m processed a lot of
logic, handled a few quirks, and aggregated data sources:

H      {  G  }
A ---> {  P  } ---> User
L      {  M  }
          ^
          |
gnome-phone-manager

In the new model we have this, where g-p-m is just a thin shim, and is
used for presentation and policy:

D      {G}
K ---> {P} ---> User
P      {M}

In the new model, we pass around object paths, and don't build up an
cached array of devices. Needless to say, it's much simpler, and it is a
much better model.

Where we fail in this new model is taking data from the session and
pushing it down into DeviceKit-power. In the example with
gnome-phone-manager it connects over bluetooth in userspace, and polls
for the battery state, and other network information. We can't have
gnome-phone-manager connect to the same device as DeviceKit-power.

In an ideal world we could send untrusted data from the session to
DeviceKit-power (protected by a PolicyKit method to active local
sessions). We could get gnome-phone-manager to call into DeviceKit-power
with a SetupDataPipe() which returns a fd for gnome-phone-manager to
write into. Or something like that.

This means that any session device whether it's a cell phone,
presentation clicker or a bluetooth mouse battery can be supported
without having to open it system level.

I know, in an ideal world the device would sprout a power_supply class
and we could just key off that, but some stuff like this has to be done
in the session. Unless I'm missing the obvious.

Comments?

Richard.


_______________________________________________
devkit-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Reply via email to