dbus Digest, Vol 12, Issue 1

Corey Brenner coreybrenner at yahoo.com
Tue Feb 1 15:12:35 PST 2005

--- dbus-request at lists.freedesktop.org wrote:
> We need to know the use case. If it's per-homedir
> you can do one set of things, if it's a "command
> line session" you can do another. When do you use
> the "command line session" bus vs. the regular
> session bus? Those are the kind of questions I
> don't know how to answer without a specific app
> in mind.
> Havoc

I've thought about this independently for some time,
and I think the arrangement should be thus:

System Bus:
   Apps (from any user, with ACLs or whatever, etc.)
   may connect to this system bus, and register for
   events (/foo/bar has changed state, etc.).  This
   could also allow for something like /bin/login to
   query the system bus for a standard user environ,
   and other configuration (obviating the wacky
   stuff in /etc for each shell, bringing them all
   under one config management.)  This allows
   login shells to be notified when the system's
   config has been changed, or when it's time to shut
   down for maintenance (obviating part of "lsof"), or

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

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.


Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.

More information about the dbus mailing list