dbus Digest, Vol 12, Issue 1
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.
I've thought about this independently for some time,
and I think the arrangement should be thus:
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
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
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