User bus conclusion

David Zeuthen zeuthen at gmail.com
Wed Nov 10 05:38:29 PST 2010


Hi,

I think the way I'd like to see this play out is

 - we leave the session bus alone
   - that way we don't break existing apps or setups
   - for example, plenty specs already use the session bus
   - ditto apps and libraries

 - we add a new user bus; call it LOCAL_USER
   - very simple: the address is $XDG_RUNTIME_DIR/dbus/user_bus_socket
   - really don't want to spec this out for non-unix - if someone needs it
     there (to, say, port a Linux app to non-Linux) then it's up to them to
     submit a patch to the dbus spec and the various implementations

 - we add some helpful docs explaining when to use the SESSION bus
   and when to use the LOCAL_USER bus. This should be added to the
   D-Bus FAQ and probably also the API docs for both libdbus-1, gdbus
   and other bindings. Heck, also add examples for SYSTEM
   - FWIW, I don't think it's hard to come with examples for both
     - LOCAL_USER: Vfs, Settings etc.
     - SESSION: e.g. panels, authentication dialogs, other
       per-session stuff
     - SYSTEM: hardware stuff, networking, authorization,
       user mgmt etc.

With this setup, each desktop and/or OS can then make up its own mind
about whether to use the user bus or session bus for various things
[1].

Specifically, I don't want to see us (the D-Bus project) make
judgement calls on whether it's a good idea or not to create and/or
maintain desktops that support "multiple graphical logins". Neither do
I want us to break existing setups even if a lot of us agree that such
setups aren't workable or whatever. It's just not the right level in
the stack to make such judgement calls.

Thanks,
David

[1] : with my GNOME hat on, I'm squarely in the camp that we'll move
most of our infrastructure to the LOCAL_USER bus. Maybe even all of
it, I don't know.


More information about the dbus mailing list