User bus conclusion

[Ryan Lortie]

On Tue, 2010-11-09 at 22:55 -0500, Havoc Pennington wrote:
> I don't understand how a clear name is ridiculous.
> DBUS_BUS_USER_ON_HOST seems pretty straightforward.

Fair.  Lennart?

> > I disagree for a couple of reasons: mostly because this concept of
> > "session" is getting more and more confusing and the idea of first login
> > to last logout (including multiple distinct graphical logins)
> 
> Whoa, there are multiple distinct graphical logins? I thought one X
> server would get reused.

I mean distinct but not simultaneous:

 - start ssh login
 - start X login
 - end X login
...later...
 - start X login      (still in the same session...)
 - end X login
 - end ssh login      (session only ends now)

> A session in the sense of dbus session bus is just any collection of
> processes that should start and stop together, really. And the
> collection of processes should include exactly one X server or some
> current apps will get confused. App developers need to know they don't
> have to dick around with being able to have N
> screensaver/input-method/clipboard-manager/gnome-panel/etc. services
> on one bus.

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.

> Leaving this open seems to run counter to the rationale for making the
> change in the first place. Nail it down!

Yah... nothing like a good healthy dither on a strong proposal. ;)

> I think the dbus spec could just document that it's guaranteed the
> session bus will be 1-1 with the X server, and if you like it's
> guaranteed the session bus will not accept apps running on another
> kernel instance (another VM, another physical host, whatever). Those
> two guarantees could be implemented with the current model or with the
> proposed new model, right?
> 
> From an app perspective nothing is really changing here, so there
> shouldn't be API/cognitive churn. The main change is that now people
> don't have to do their own locking for hardware-accessing services as
> long as they know a particular user has claimed the hardware?

There is churn in any case.  Many existing users of the session bus
assume that an X server is always running and that they can always
launch graphical applications (telepathy launches empathy, some backend
launches a password dialog, etc).

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).

Cheers