User bus conclusion

[Ryan Lortie]

hi,

I really have two main points in this argument:

1) We _need_ a user bus with strong uniqueness promises.  Always.

2) Abusing the session bus into this role is inappropriate.

On Wed, 2010-11-10 at 08:38 -0500, Havoc Pennington wrote:
> I'd implement "allow the OS to choose" by just having a session bus,
> and saying the OS can decide whether a new tty/Xdisplay means creating
> a new session, or joining another view to an existing session.
> Otherwise, apps have to deal with the OS choosing, which is a mess.
> What am I supposed to do about this in my app?

This is unacceptable for me.  dconf wants to know for absolutely certain
that there is a bus that is shared by all instances of the current user
on the local machine.  It doesn't care if multiple X servers are
running.  It doesn't care if the user is coming from a text console or
ssh.  It doesn't care about vendor decisions regarding the validity of
these things.  It just needs to know with absolute certainty that the
bus that it connects to is scoped to user-on-host.

I believe that this will never happen with the session bus, regardless
of what we tell people to do.

> So if you want to support both, then just have the more limited
> guarantees of the current bus... add to them the rule that there's
> just one X server (at a time, I guess), and that there's no remote tcp
> access... done? Now the OS can merge new logins to an existing
> session, or not, whatever. Correct usage of dbus won't care.

Merging logins into an existing session bus has some complications as
well, like "smuggling" of the environment variable that defines the
session.  It also means that we can't avoid the whole bus-autolaunching
mess without changing the spec in an incompatible way.

This approach gives me a strong "ick" feeling for aesthetic reasons.

Cheers