User bus conclusion

[Havoc Pennington]

Hi,

On Tue, Nov 9, 2010 at 10:09 PM, Ryan Lortie <desrt at desrt.ca> wrote:
>> If you insist on a new name for the bus in the dbus APIs, please use
>> USER_ON_HOST or something, not just USER, for the enum value.
>
> We considered really a lot of names, including the rather ridiculous
> SYSTEM_USER and USER_SYSTEM.  We settled on USER as being the
> least-ridiculous.

I don't understand how a clear name is ridiculous.
DBUS_BUS_USER_ON_HOST seems pretty straightforward.

People who've asked for a user bus in the past were often thinking it
was going to solve a particular problem for them that this is not and
cannot. Pretty sure you can find some examples in the list archives.
You're keeping the concept of multiple buses per homedir and per user
(assuming a network user database / homedir-server). App authors
should be able to suspect there's some subtlety here without reading
the docs first.

That said just leaving it called SESSION is not ridiculous either.

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

It sounds to me like you're doing a "screen" style setup where there's
one session, but you can attach to it from multiple logins. i.e.
basically you're making the login irrelevant, just a way to
authenticate to and join a session. That seems like a logical model if
you want to prohibit multiple buses, is to just declare there's a
single session that can be joined from multiple ttys. Simple.

> is not
> something that most people would call "a session".

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.

> The second reason is that we may want to keep the session bus around for
> some of the special situations that Lennart mentioned.
...
> We briefly discussed the possibility on IRC that we would keep both
> "user" and "session" busses and let applications decide what they want
> to use based on their intention

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

I don't even understand the proposal. If I'm an app then why in the
world would I want to be per-time-the-user-typed-their-password
instead of per-collection-of-apps-working-together-with-an-optional-X-server?
Maybe some PAM/login-related stuff but that's about it, and that's not
worth running a bus.

This seems too complex for app authors to ever understand.

If there's some hypothetical future bus for weird cases, name that
something new. Name the bus for the desktop session, that everyone is
using now, and should keep using, the session bus. Just change
when/how the OS launches it. Much simpler.

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?