dbus Digest, Vol 12, Issue 1
hp at redhat.com
Tue Feb 1 16:37:12 PST 2005
On Tue, 2005-02-01 at 15:12 -0800, Corey Brenner wrote:
> User Bus:
> All bus-aware apps on a given host may hook into
> this bus. Traffic may be exported to other
> by SSH-forwarding, etc., but the real point is to
> have a central point for user-global
> which may be instantly realized in all the user's
This is why gconfd was per-user of course, but all the same problems
with gconfd come up. The real solution IMO is to have gconfd (or
equivalent) able to see changes to its config files and update from
there, or alternatively to have a client-server architecture (rather
than write files, have gconfd store the data on some type of server that
all gconfd are connected to).
However, when it comes down to it instant update of all sessions is cool
but not very important. Lots of apps don't have this feature, and
breakage in the face of firewalls or other complexity very much
outweighs the value of instant update that spans sessions. People are
pretty happy with apps (Firefox, openoffice, etc.) that don't have this.
It turns out to be fine if you have to change the setting twice _or_
just log out and back in on one of the sessions.
So in short I don't think instant update of config is enough use-case to
justify a user bus.
> Session Bus:
> A special application of the User Bus, which may
> ride atop it by specifying a session ID to which
> session-aware apps on the local host (or, if the
> bus has a router listening, session-aware apps on
> a different host) pay heed. Making the Session Bus
> ride atop the User Bus allows a user to have many
> concurrent "sessions", which all heed the User Bus'
> global messages, but which communicate with each
> other by specifying a session ID on the User Bus.
The session bus is not supposed to be some sort of bad substitute for
the user bus; per-session scope is what you usually want for desktop
stuff. Most of the desktop is scoped per-session already.
More information about the dbus