User bus conclusion

[Lennart Poettering]

On Wed, 10.11.10 09:09, Havoc Pennington (hp at pobox.com) wrote:

> > Even now you're making it sound very much like a session is tied to a
> > particular X server.  If we keep the SESSION bus, I think it should
> > definitely include exactly one X server (as you mention), which is not
> > what we are proposing here.
> >
> > What we propose here is that the USER_ON_HOST bus has either zero or one
> > X server and that one X server might change over time.  This really is
> > something different.
> 
> It's different but pretty much accomplishes the same goal. The point
> of the 1-1 with X server is to avoid ambiguities like:

Note that while I know that you intended that there was a 1:1 mapping
between bus and session this is not really what is the status quo right
now. In another mail you even suggested ssh'ing to another machine and
starting a seperate bus there. In that case, there would be one screen
with two busses.

I also see little changing in this respect. Previously we had one screen
shared by multiple busses, and we will continue to have that.

> > It also seems clear that no matter what we decide here, some people will
> > continue running multiple session busses for multiple sessions (in the
> > intuitive sense of the word) in which case the strong assumptions about
> > the user bus (as described here) are no longer true.  Lennart even
> > mentioned some cases where this was sort of legitimate (gdm, for
> > example).
> 
> My take is that you _either_ declare that unsupported, and get the
> benefits of your model for apps; or you keep essentially the current
> model (at least from the perspective of apps, they remain
> theoretically required to handle multiple sessions per user). If you
> don't declare multiple sessions per user unsupported, then nothing
> changes for apps. They have to handle the current model _anyway_ or at
> least feel guilty about failure to do so. The only win for apps is if
> you rule the multi-session model out and say all sessions are
> unisessions.

So my take on this is that in the long run we should deprecate session
busses, and go only with user busses. In the short run however, we
support both and redirect requests for a session bus to the user bus
unless explicitly configured otherwise. 

Before we can go all the way with the user bus we'd need stuff like
dynamic uid allocation which we currently don't have, to deal with kiosk
setups and gdm.

The stuff running in gdm in the greeter is actually numbered. So as long
as we continue to ensure that this limited session actually works, we
should be fine with otherwise going to user stuff. And the kiosk stuff
already is semi-broken anyway since stuff like firefox doesn't allow
spawning two instances at the same time from the same $HOME.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.