D-Bus User Bus

[Havoc Pennington]

Hi,

On Wed, May 19, 2010 at 10:28 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> Claiming that there was a 1:1 relation ship between a display and a bus
> is not right, because our session busses are *not* network
> transparent right now. (And I'd claim rightly so)

This is a bug and always has been, though, according to the current design.

Yes, running X apps as different users or on different machines from
the main session is a Mess. See the bug about su I'm too lazy to dig
up. Different machine and different user via su are pretty similar
cases. The whole "how that should work" is so undefined and such a can
of worms it's tough to use as an argument here, though, since the user
bus just makes it even harder to sort out ;-) and to date nobody has
written down what should work, what should not work, and how to write
an app correctly such that it all does work...

> If the display goes away it should be libX11/libgtk that makes an app
> quit, not libdbus. If you want to bind lifetime of a process to the
> lifetime of a display, then connect that directly, don't involve the
> bus.

The idea is to give nongraphical services a way to exit at the right time.
This has been documented (or at least frequently emailed) as one
"point" of the session bus since the creation of the session bus.

> The last point is actually something we should think about more: network
> workstations are mostly focussed on vnc-like solutions these days, not
> x11/nfs like solutions.
>
> Getting apps right that work correctly on a shared NFS with multiple
> logins on different machines is even harder than getting it right on a
> single machine, simply because NFS is a PITA when it comes to
> concurrency and nobody gets that right. Maybe we should just stop caring
> about that case, and gtk should create an NFS-safe lock that makes it
> impossible to run an apps that way.

If this is declared as policy and you can pull it off then it
certainly simplifies a lot of things. But I do think it's a bigger
change than we should "enforce" after just a discussion on this
mailing list.

Havoc