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