D-Bus User Bus

[Lennart Poettering]

On Wed, 19.05.10 22:19, Havoc Pennington (hp at pobox.com) wrote:

Hi,

> On Wed, May 19, 2010 at 10:11 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> > You are writing this as if there was any value in strictly seperating
> > multiple sessions of the same user from each other. But there is none.
> 
> The value is: it's a simple model that matches the X server model, so
> X server and dbus-daemon are co-scoped. Historically people understand
> this and it works. It's also what's documented and how it's worked for
> a long long time.

That is simply false.

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)

> If you go per-user (instead of per-session; an alternative would be in
> addition to per-session, at complexity cost), then now you have the X
> server with behavior/scope A and dbus-daemon with behavior/scope B,
> and they don't have the same lifetime. That is harder to understand,
> and for most GUI apps, not what is wanted. It's also an ABI break,
> pretty much. I would predict that tons of stuff assumes the session
> bus has session scope.

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.

> *Adding* a per-user bus is less disruptive, but then you have to ask
> whether it's really worth having yet another bus, or whether the
> system or session bus could be made to work for the per-(user,machine)
> case and I think they pretty much can. But adding a per-user/machine
> bus is certainly more sane, imo, than replacing the session bus. I
> don't think *adding* the per-user bus is broken, just kind of
> overkill; *converting* the session bus to per-(user,machine) I think
> is likely to end up pretty broken. But, maybe nobody cares about
> network homedirs anymore. I haven't used one personally in many years.

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.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4