DeviceKit-power future plans

[David Zeuthen]

Hi,

I finally had some time to look at it. It looks pretty good, thanks for
hacking on this! Some comments (I mainly looked at the external
interfaces, not at the implementation)

 - The output "data" parameter of Device.GetStatistics() of type
   "a(uds)" is not documented.
   - see e.g. http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device.DriveSmartGetHistoricalData

 - The Suspend() method on HAL takes a parameter on how long to sleep;
   AFAIK no one uses this mostly because the wakeup code in Linux sucks.
   The one on DeviceKit-power doesn't. Should it?

 - The udev rules should probably use DKP_ID_BATTERY instead of
   ID_BATTERY. Just to be nice and not pollute the main name space.

 - What's up with the libdevkit-power? Is this a C wrapper for the D-Bus
   service? I think we want to export this... just use proper and nice
   D-Bus bindings instead.

   - and if do want this
     - should be licensed more liberally (MIT instead of GPL)
     - consistency!

       - .pc file should be called devkit-power
         - not devicekit-power

       - name of the .so file should be libdevkit-power
         - not libdkp-power

       - headers should be in /usr/include/DeviceKit/devkit-power
         - not /usr/include/DeviceKit-power/dkp-gobject


On Tue, 2008-08-05 at 08:29 +0100, Richard Hughes wrote:
> * add the suspend and hibernate hooks in properly (just supporting
> pm-utils) -- quirks still to do.

I don't see why DeviceKit-power should be involved with dealing with
quirks - I think we should just punt the quirks to the pm-utils project,
e.g. make sure that project delivers the right quirks if the system
needs it (and I think pm-utils should just use udev rules but that's up
to the pm-utils maintainers). 

>  * bloating the public D-Bus interfaces

Yeah, I'm concerned about that too. Doesn't look to bad so far!

>  or support
> for obsolete technologies (/proc/acpi, /dev/apm)

Yeaj, definitely not going to happen.

     David