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