org.freedesktop.PowerManagement

[Alp Toker]

Richard Hughes wrote:
> On Wed, 2007-03-21 at 18:36 +0000, Rob Taylor wrote:
>> Does it need a signal for the capabilities changing? e.g. if not on an
>> active console, or permissions have changed?
> 
> Ahh. Valid point.
> 
> That would require signal like CanSuspendChanged and CanHibernateChanged
> unless we use your bitfield thing.
> 
>> It might also make sense to just have a Capabilities bitfield rather
>> than seperate calls for Suspend, Hibernate, Reboot and Shutdown. You're
>> gonna call all of them at startup anyway, so makeing it one call reduces
>> bus round trip considerably.
> 
> Sure, I appreciate that. Using a bit field does make the API more
> complex (replying on magic constants) rather than a simple boolean
> output. I'm open to doing it using a bitfield if this is common
> consensus, but I must admit I like the individual API myself.
> 
> In a typical scenario, we only make 4 calls to o.f.PowerManagement to
> the same interface which take a very small amount of time.
> 

I think that these are best kept as individual calls -- it doesn't imply 
round-tripping at all. If using a low-level D-Bus API, calls can be made 
in one go and the replies waited for. There are even languages using 
managed D-Bus (and I think libdbus too, do those guys have a Haskell 
binding?) that are capable of latency hiding and will do this automatically.

Moreover, even if applications don't use a "smart solution" here, one 
assumes the programs will only suffer the tiny roundtrip overhead once, 
at start up, and will watch for signals thereafter.

NAK on this one.