Re: Session DBus protocol

[Lennart Poettering <mztabzr 0pointer de>]

On Mon, 25.10.10 16:01, Ryan Lortie (desrt desrt ca) wrote:

> hi,
> 
> Vincent and I are sitting on a couch here at UDS reviewing the DBus
> protocol used by gnome-session.
> 
> I am interested in adding support to GtkApplication.
> 
> My biggest concern is that the "emit signal and wait 1 second" approach
> for checking which clients want to stop the logout from happening is
> really bad.
> 
>  1) Some clients might miss the deadline (if they are swapped, or the
>     system is really bogged down).  Data loss here.
> 
>  2) We may end up waiting for 1 second completely unnecessarily.
> 
> 
> I was wondering if maybe we could improve this interface to work more
> like the following:
> 
>  1) Clients that may want to block the logout register themselves with
>     gnome-session.
> 
>  2) gnome-session does a AddMatch on their NameOwnerChanged so it can
>     tell if they exited (and unregister them).
> 
>  3) At logout time, gnome-session makes a method call to each registered
>     app and *waits for a reply*.  The length of time to wait should be
>     much longer than 1 second.  Similar to the close button on
>     unresponsive windows, we could pop up a "this application is stuck"
>     dialog in that case allowing the user to kill it if they explicitly
>     choose to (but never assuming that no reply equals "no data to
>     save").

Instead of having clients register with gnome-session I'd simply make
them take a prefixed name on the bus.

i.e. take "org.freedesktop.SessionInhibitor.Foobar" or so in an app
"Foobar" (or include the PID or some other id as suffix). Then g-s
should just watch all those prefixed names and log off as soon as none
of them remain. And of course, add some dbus iface to the apps to make
those apps quit (but I figure gtkapplication has that anyway?).

In general I do believe we should use the dbus name registration for all
those "registration" use cases, instead of having client-to-client
registration. It's nicer for loose coupling (because clients can just
take the name, and need no fallbacks/error checking in case g-s isn't
around), and also more robust, and less duplication. And, last but not
least, it allows for a greater amount of parallelization, which (with my
systemd hat on) I can only welcome!

Also, it minimizes the dbus function calls you have to do. On startup of
all apps you just need to take a name, which only travels to the bus,
and can be done asynchronously without expecting a reply. On shutdown of
the apps, don't do anything. On session logout in many case you just
need EnumerateServices, which needs to be sync. And to ping the
individual clients you just need one sync msg each. I don't think it can
get any better than that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.