User bus conclusion

[Havoc Pennington]

Hi,

On Wed, Nov 10, 2010 at 10:14 AM, Havoc Pennington <hp at pobox.com> wrote:
> I'm not saying there isn't such an idea as a user bus. I'm saying your
> proposal isn't it. Your proposal is a user session, which then implies
> the session bus is per-user. That's different from having multiple
> sessions, and a user bus that spans them.
>

One thing to add, a really _bad_ road (in my opinion) would be if the
thing called LOCAL_USER in the dbus API was sometimes the session bus
for a per-user session, and sometimes a bus spanning multiple sessions
with multiple X servers. That would leave ambiguous how to use the
user bus: can you do anything graphical on it? Do you have to scope
services per display? Should you use the session bus instead and when?

So I don't think that model (which is what I'd call a user bus;
keeping sessions as-is and adding a new user bus spanning N sessions)
should be left as a possibility.

If it is a possibility, then I think _it_ is the thing called user bus.

In the two OS configurations:

a) if the OS has per-user sessions and you have to join the existing
session when logging in, then the user and session buses just have the
same scope and having two is pointless. But if any apps are using two,
you probably have to have two. Maybe it works to have one bus that you
get if you ask for either user or session bus? So one daemon acts as
both buses.

b) if the OS has a session per login, then there are N session buses
and 1 user bus.

So, I don't much like having two daemons, because it just isn't worth
the headache. But if you were going to have two, I believe the one you
described and that you'd mostly use is still the session bus. The user
bus is only useful in OS config b), which you guys don't even want to
support. And the user bus is only useful in OS config b) in a few
cases where you want per-user per-machine uniqueness, and don't want
to mess with the X display, right?

I think you can build OS config a) and get it all working without ever
even touching dbus, honestly. (Other than maybe some incidental stuff
like supporting systemd better, but no API changes.) The thing that
requires work in dbus is to have a "true" user bus, in case b), that
spans multiple sessions. But I really liked the aspect of your
proposal that just decided not to support that.

Havoc