alp at atoker.com
Wed Mar 21 13:15:12 PDT 2007
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.
More information about the xdg