org.freedesktop.SessionManagement

[Oswald Buddenhagen]

On Tue, Apr 03, 2007 at 12:04:43PM +0200, Patryk Zawadzki wrote:
> On 4/3/07, Oswald Buddenhagen <ossi at kde.org> wrote:
> >On Tue, Apr 03, 2007 at 09:07:13AM +0100, Richard Hughes wrote:
> >> No, we need to provide a way for clients to delay (think to save a
> >> file) or to cancel the shutdown (say encoding a file),
> >
> >> although the latter use case can be dealt with using the more suited
> >> inhibit system.
> >>
> >fwiw, i don't think it's more suited (why should it?).
> >given that the callback mechanism is necessary anyway, why introduce a
> >second system that manages state in the service?
> 
> What about system-level apps that need to inhibit (think daemons)?
> They have no session daemon to register to.
> 
but a system daemon, obviously. i don't see a difference.

> System-level locking is still needed and it's more suited as it does
> not require you to register any foobar callbacks that just return
> FALSE, instead you just obtain a lock on a specific HAL device and
> free the lock when you're done.
> 
otoh you have to update the state known to HAL every time it changes, as
opposed to returning it only when asked for.
the only real advantage i can see is that the lock request variant does
not require an event loop in the client, but where isn't that provided
anyway?
other than that, it seems to be just a matter of taste ...

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.