User bus conclusion

[Havoc Pennington]

Hi,

On Wed, Nov 10, 2010 at 9:52 AM, Ryan Lortie <desrt at desrt.ca> wrote:
> I really have two main points in this argument:
>
> 1) We _need_ a user bus with strong uniqueness promises.  Always.
>
> 2) Abusing the session bus into this role is inappropriate.

What I'm saying is that your specific proposal for how the user bus
works (which is different from some past proposals) is to have one
session, with 1 X server at a time, which gets joined anytime the user
logs in. i.e. you are really adding a "user session" - not JUST a
"user bus." And I think that's right, it's a good way for it to work.
If you do a user bus while still also having multiple sessions, then
you get into all kinds of mess, at least if the user bus is allowed to
use the X display.

You aren't abusing the session bus, because the basic change is _not_
to dbus. It's to the OS. You're making sessions per-user instead of
per-login. That's what makes the whole thing go.

If you did the user bus differently - so you had N sessions, with N
displays and session buses, and you shared the user bus among those -
then now the user bus has multiple X displays on it, and it's
genuinely distinct from the session bus. However, I think that model
is too complicated and difficult for app developers, personally, and
it's overkill.

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.

Havoc