User bus conclusion

[Havoc Pennington]

Hi,

On Wed, Nov 10, 2010 at 3:48 AM, Ryan Lortie <desrt at desrt.ca> wrote:
> 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)
>

Yeah, I think that works fine. Basically X apps would exit with the X
server and restart later, while non-X-dependent would exit when there
are no logins. Which makes total sense.

> 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:

 * if the X server exits, should my app survive in order to appear on
other X servers?
 * do I have to put some ID for the X display in my service names to
have one instance per display?
 * exactly when does the session bus exit? is that the right time for
my service to exit too?

There are good clear answers in your approach that are pretty much the
same as the current answers.

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

The two models are different for the OS implementation even if both
are supported, but from an app perspective, only the one with the
weaker guarantees can be assumed to exist and the stronger-guarantees
one is just confusing noise.

Havoc