org.freedesktop.SessionManagement

[Patryk Zawadzki]

On 4/3/07, Oswald Buddenhagen <ossi at kde.org> wrote:
> On Tue, Apr 03, 2007 at 12:04:43PM +0200, Patryk Zawadzki wrote:
> > 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.

If Register() is part of the session management interface, then it is
provided by session-level daemons. Thus no candy for system level.

> > 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.

Still - it's meant to be used by critical applications. For example,
rpm might only want to inhibit while starting the (un)installation
process and free the lock when it's done. This is nothing more than a
system-wide non-exclusive semaphore.

> 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 ...

Method 1:
Obtaining an inhibiting lock is just one call. Freeing the lock is a
second call.

Method 2:
Using Register() is one call. Unregistering is a second call.
Yet you still need to write the callback and incorporate handling the
callback into your event loop.

The problem is single-tasked apps like rpm or might not even have an
event loop as they just usually:

printf("Doing stuff..."); doStuff(); prinft(" done\n");

If there is no required interaction, there is no need for an event loop.

-- 
Patryk Zawadzki
Generated Content