DeviceKit-power release next Monday

[Patrice Dumas]

On Thu, Oct 08, 2009 at 10:31:22AM -0400, David Zeuthen wrote:
> 
> One of the main features of udev and DeviceKit-disks (and the GNOME
> desktop shell for that matter) is that we closely track changes made to
> devices. This means that you can use existing and well-known tools such
> as mkfs(8), fdisk(8), e2label(8), mdadm(8) and so to make changes.

Ok (but I sort of assumed it, in fact). However, the authentication 
path is different from using the DKd interface, which means that
it may still be relevant to go through an app that uses the DKd 
interface although it does exactly the same than these command-line
applications.

> For features not covered by existing tools, such as configuring drive
> spin down globally etc., there's the devkit-disks(1) command line
> utility. We could teach devkit-disks(1) about creating partitions /
> formatting but I'm not sure it's worth the effort.

That's what I was more concerned about, features that can be accessed
only through DKd.

Maybe the best solution would be to have a second command-line 
application beside devkit-disks(1) that is a simple layer above DKd 
like devkit-disks(1), share some code with devkit-disks(1), do what 
devkit-disks(1) doesn't but is separate to avoid risking to add bugs
in devkit-disks(1) and allow to experiment, for example for the 
options syntax (and maybe have features merged in devkit-disks(1) 
after some time when it has proven it was useful and not buggy).
 
> > application that shutdown devices when power is low and they were idle
> > for a certain amount of time, or simplly a command-line app to suspend the
> > computer (maybe devkit-power will do that, though).
> 
> There's devkit-power(1) and we could add --suspend and --hibernate
> options. Also looks like the man page is out of date. Suggest to file
> bugs for these things at our bug tracker at bugs.fd.o.

I was more thinking about a possibility to shutdown specific devices,
for example some usb devices and not the computer itself. But I am not
sure that DKp does that anyway.

> Anyway, this kind of toolkit API should go into GLib which is not really
> GNOME specific. In fact, a ton of the system-level software on Linux use
> it. If you don't like GLib, just use another toolkit, write your own

As I said previously, GLib is okay for me. And if not, I'll certainly
try to replicate the DK* specific GLib API in a more ligthweight 
library, but I am quite convinced that it is not worth it.

> toolkit or just call directly into DeviceKit-power. Of course, the
> DeviceKit-power ABI may break but that's kinda your own problem since
> you decide to be picky about things ;-)

As I also said above having an unstable API (and not backward compatible)
doesn't seems to me to be an issue, especially now that all this is new.
In a few years, maybe it would be nice to start to have avoid backward
incompatible changes, but that's your choice anyway.

--
Pat