Dbus daemon

[Robert McQueen]

Thiago Macieira wrote:
> This breaks the concept of "session" bus.
> 
> What you described is actually a "user" bus. All sessions share the same 
> bus.

I know, but if you're in a shell, a session bus which is limited to just
that shell is pretty useless. People use hacks like this (or slightly
more polished things, but hacks all the same) for sharing stuff like
their ssh-agent on multiple logins, which was also conceptually designed
to be a per-session thing just like dbus-launch.

It's already been discussed multiple times on the list and apparently a
user bus is too confusing or not really useful unless you make it a user
bus shared across a network cluster. I don't agree, and I think that the
consequence of this stance will be a proliferation of hacks like the one
I just sketched out (not to mention even grosser hacks like Ubuntu's
ACPI scripts grepping the environment of the user's processes in /proc
to find their session bus to tell their screensaver to lock).

However, I don't have time at the moment to implement even a per-machine
per-user bus, let alone a network-spanned bus [1], so all I can do is
comment why I think a user bus would be better than the gross hacks
we're implicitly encouraging. I do hope to get to it at some point
because Telepathy would hugely benefit from a per-user bus, and I think
that patches which do things like bring gconf and eds onto D-Bus also
really want a user bus, not a session bus.

Regards,
Rob

1: Although designing a daemon-to-daemon protocol would allow you to
serialise the state of one daemon to another, pass over the connections,
and then also be able to solve the "can't restart the system bus without
rebooting problem"... :D