per-user dbus

[Simon McVittie]

On Wed, 11 Nov 2009 at 01:39:40 +0100, Lennart Poettering wrote:
> OTOH dconf, geoclue, gvfs or telepathy don't have windows on the
> screen and deal with data that is shared among sessions. They should
> live on the user bus.

One problem we've seen in a real-world use of D-Bus is that if you have two
D-Bus connections, you lose the total-ordering guarantees. As a result, if any
of an app's functionality goes over the user bus, that whole "module" should
use the user bus.

This is tricky in Telepathy, because we do rely on the bus's total-ordering
guarantee for the correct operation of Clients (UIs, basically), to get
events delivered to a Client in an order that doesn't leave it guessing about
the context of something it's being asked to do. So, if we move the channel
dispatcher (Mission Control) to the user bus, Empathy's Client interface
(by which Mission Control tells it to handle a particular channel) would also
have to move to the user bus.

For a while, Maemo's libdbus was broken in such a way that if you asked for
the session bus and for the starter bus, you got two DBusConnection instances
pointing at the same bus. Half of a Client's functionality went over
each of those, resulting in races between reads from the two sockets, and
messages sometimes happening "in the wrong order" - it took a long time to
debug this, and for a while we even suspected that dbus-daemon was reordering
the messages!

Another practical point about the user bus is that the bus to be on should
be considered to be part of the API/ABI, so changing it should be a "flag day"
like any other API break (in the case of Telepathy we'd wait until we're
breaking API anyway, which we plan to do once before Telepathy 1.0).

    Simon