Missing user bus?
Robert McQueen
robert.mcqueen at collabora.co.uk
Thu Sep 22 06:01:35 PDT 2005
Currently the specification for D-Bus outlines a system bus, which is
per-machine, and a session bus, which is per-machine-per-user-per-login,
and comes into existence when you log in, and goes away when you log out.
I've got a few ideas of things which are currently (and some stuff I'm
writing) being made to use the session bus which are actually not per
session at all, and could well be better served by the addition of a
third "user bus" (ie per-machine per-user) which can (but doesn't have
to) persist between sessions. They can fall into one or both of two
categories: those services which should not be duplicated if you log in
multiple times, and those services which should be able to persist
across logins.
The former are things like evolution-data-server and gconfd, where your
address book and preferences are clearly per-user and not per-session,
so if you log in twice there's no good reason to spawn them again. The
latter are things you don't want to go away between sessions, the
example I'm thinking of being something like a connection to an IM
server which could stay around and log your messages or forward them
somewhere else, but you want your client to talk to it normally next
time you log in.
Its tempting to say that it might be desirable to refcount the session
bus, have the new session "find" the existing session bus, and then
terminate the session bus only when all sessions have logged out. I
don't think this is the correct solution at all because it breaks the
defined semantics (log in -> start, log out -> end) of the session bus,
which are still useful in many cases despite the exceptions I've mentioned.
Firstly, even though there are things as well as the per-machine
per-user services I mentioned, there are definitely things that you do
want to be session-specific - if you ask your browser to spawn a new
window, you don't want it to find your browser in your other session and
open one there. Secondly, doing a refcounted semi-persistent session bus
also doesn't really provide a sensible way of persisting user-specific
bus services on a given machine between logins.
I think adding a third bus type of a user bus (more persistent than a
session bus, but per-user unlike the system bus) would address both
problems. It could be created when necessary, and represent itself with
a unix socket on disk in a per-user determinable location (in per-user
directories in /tmp or your home dir for example) protected by
filesystem permissions. The daemon would stop when all the services went
away - in some cases these could time out after no use as they currently
do (eds, galago, gconf) or if they represent a persistent resource (IM
connection) keep the user bus around while the resource exists.
Comments? Should I write a spec (and maybe a dbus :D) patch?
Regards,
Rob
More information about the dbus
mailing list