User bus conclusion

[Havoc Pennington]

Hi,

On Sat, Nov 13, 2010 at 9:32 AM, Matthew Johnson <dbus at matthew.ath.cx> wrote:
> Whether or not to allow more that one login for the same user is not something
> which it is up to us to decide. Whether or not you think it's a good idea
> (sure, it's _simpler_, I guess we should just give up on anything that's
> slightly hard, right?), but D-Bus cannot make this decision for people.

Well, as I said I think it's really more of an OS change. If the OS
says the session (and session bus) is a singleton per-user, then any
apps or desktop environments that want to require that can then rely
on a per-user session bus (along with per-user
everything-else-in-the-session such as X server).

The dbus change is if we want a user bus even with multiple sessions,
AND a session bus, which is a discussion that's been had many times. I
think this is a completely separate decision - or almost completely
separate anyway - from whether multiple sessions are allowed. I'm not
a fan of the way the two discussions got a little mixed together in
this thread (if not clear, I think it's because of calling per-user
sessions "user bus" when that per-user session change doesn't actually
affect dbus at all).

The one relationship between the decisions is that if you have
per-user sessions, then separating the user bus and session bus
becomes clearly 100% pointless, while if you have multiple sessions
there's some arguable (IMO pretty weak, as discussed on several past
occasions) reason to have two buses. I think that's where the thread
got confusing, because the OS change does affect the historical user
bus discussion in the sense that it may render it irrelevant.

To be clear, my possibly-irrelevant .02 is that the proposal that
started the thread is an OS change that doesn't imply the dbus spec
taking a position on it. What the dbus spec _could_ take a position on
perhaps is that sessions can only have one X server in them, or some
other stuff like that. Or the dbus docs could just say that "expected"
OS configurations would have properties xyz whatever they are.
I don't know.

In any case I don't think dbus should get too jumpy about any of this
until someone has it prototyped out in a real OS to see what happens
and what the details are... the OS change can clearly be tried out
with the session bus. The user bus discussion/patches can be separated
entirely... at least I don't understand why not.

> Sure, people will hack around you when you break things, but that's not an
> excuse for breaking them because you can't come up with a real solution.
>
> Whether or not the solution is complicated is not a good reason not to do

Well, nobody has come up with a solution in the last 15 years, so I'm
not holding my breath. Usually (like on that bug about sudo/su)
there's just a lot of people saying this should work, that should
work, and nobody has _ever_ that I know of documented _all_ the things
that should work, and the rules apps and the OS would have to follow
to make them work...

To be clear though I agree the OS or GNOME or some party like that
should do the defining of what will work and not work, I don't think
dbus or this mailing list are the place to decide it.

Havoc