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.
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
