D-Bus User Bus

[Lennart Poettering]

On Sun, 16.05.10 16:13, Havoc Pennington (hp at pobox.com) wrote:

> 
> There are extensive threads on this in the archives. Before changing
> anything I'd surely suggest digging them up and linking to them for
> everyone.
> 
> The big problem in the past - and the reason we have a session bus -
> is that per-user stuff, such as Bonobo and GConf - just did not work,
> ever. Nobody got it right. While the per-session approach, used
> historically by most things (and by KDE) did work. So KDE (in
> practice) supported multiple logins, GNOME (in practice) did not.
> 
> The failure mode usually involves network homedirs (multiple machines)

I don't see how the network problem makes a difference for whether we
share a single gconfd between two local sessions of the same user or
have two instances instead.

> While a user bus fails badly by default because handling multiple
> displays on one bus requires app programmers to do a lot of work.

Well, I acknowledge that, but what I propose would simply make it
official that most programs cannot deal with multiple simultaneous
logins at the same time.

> Basically if app programmers are clueless, user bus breaks due to
> multiple displays, session bus mostly works because "last to write
> wins" works fine.
> 
> In essence, people won't test and won't implement the display handling
> that Lennart suggests, at least historically that is what happened
> with Bonobo and GConf. Maybe better docs or convenience API could
> help. But if app developers doing the "obvious thing" doesn't work...
> your battle is uphill.

Well, I am not too concerned with the display handling stuff being too
hard. As I tried to point out multiple times I'd say that already many
programs are broken when they are started more than once. With the
scheme I proposed we'd just change the default from "broken but claims
to work" to "refuses to work". Which I think is a good thing. And the
few people who actually care about multiple logins and have the overview
would then be able to make selected programs work with multiple
displays.

Also, I think that the upcoming GTK application class could play a role
here. With a simple flag the developer could express whether his app is
multiple-display-safe or not. And GTK would then care about the rest and
suffix the bus name that it registers with the display identifier.

> Another big problem is daemons failing to exit when people log out.
> This pisses off sysadmins, due to both resource use and problems
> getting automounted homedirs to go away. With per-session - and the
> default behavior of DBusConnection/Xlib to exit if the app developer
> has not done anything explicit - this usually doesn't happen.

Well, I don't think dbus-session makes a good session manager. We should
not confuse it with one. Process babysitting should be done by process
babysitters, e.g. systemd.

Lennart

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