Missing user bus?

[John (J5) Palmieri]

This would most likely be a post 1.0 thing.  It was brought up some time
ago in a different context I believe by n (Dan Reed) in reference to his
naim application.  YOu should check the archive for the discussion.   I
am not sure if we actually came to a conclusion. 

On Thu, 2005-09-22 at 14:01 +0100, Robert McQueen wrote:
> 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
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
-- 
John (J5) Palmieri <johnp at redhat.com>