DeviceKit-power release next Monday

[Patrice Dumas]

On Tue, Oct 06, 2009 at 07:40:48PM -0400, David Zeuthen wrote:
> Hey,
> 
> For DKD, don't expect a stable API anytime soon. FWIW, I even doubt that
> it's useful to make the API stable. It's kinda-sorta an API that is
> useful only for the OS vendor to implement a desktop environment or an

What OS vendor are you talking about, and what 'desktop environment' are
you talking about? I think that there are no such things at the DK*
level. Indeed DKD is about doing stuff with disks, this shouldn't be 
linked in any way with high level issues like how an installer or a desktop 
is done. That doesn't mean that the interface should be D-BUS based, 
but it shouldn't be desktop or vendor specific.

> Applications (that are not disk utility, partitioning etc. apps) should
> just be using the GIO API since it's simpler and do what they need

I am not very knowlegable about gnome, but it looks like very gnome centric
and not at the same level as DK at all. It even seems that it requires 
a specific daemon running.

> I think the same goes for DeviceKit-power: For the few bits where apps
> need to care about power management (if any?), GLib and/or Gtk+ really
> should provide abstract interfaces whose concrete implementation uses
> DeviceKit-power on Linux and other free platforms. GLib and/or Gtk+
> would also provide implementations on Win32/OS X/whatever that uses the
> appropriate OS specific stuff.

I really can't see how a gtk+ interface would correspond with DKP. Maybe 
GLib (to avoid reinventing low level functions), although it would be 
better if it is more independent, but gtk+ doesn't make sense to me. It 
is much too high level.


That being said, I think that a moving D-BUS API for DK* is not an issue
for the time being and maybe for a longer time, since it is not clear
to me how things are organized. Although I would not like a GIO/GTK+ based
API, an abstract API above DK* could be the way to go instead of using
directly DK, and there are certainly other possibilities. And until such 
design issues are not solved, a stable API is not very appealing.

--
Pat