User bus conclusion

[Havoc Pennington]

Hi,

On Wed, Nov 10, 2010 at 8:20 AM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
>> That would allow minor disruption to existing users of SESSION but still
>> give the benefits of USER to those who want it.
>
> I think a better compromise here could be to allow people to choose
> between a user and a session bus, but never offer both at the same
> time.
>

I'd implement "allow the OS to choose" by just having a session bus,
and saying the OS can decide whether a new tty/Xdisplay means creating
a new session, or joining another view to an existing session.
Otherwise, apps have to deal with the OS choosing, which is a mess.
What am I supposed to do about this in my app?

Maybe an app could manage something like:

 dbus_bus_is_shared_among_ttys()
or
 dbus_bus_is_unique_for_user_on_host()

that kind of makes sense.

I don't know, I mean... ugh. seems like once they handle the
non-shared/current-style session bus, they would never need different
code for the shared-across-logins session. So what's the point of this
API?

 But I'm having trouble seeing apps get this right:

 if (dbus_bus_get(USER) == NULL) {
  dbus_bus_get(SESSION);
  if (is_session) { do stuff differently? what? }
 }

I don't know. If you can handle the way the session bus works _now_
then I think you "just work" in the shared-across-logins session bus.
(This is really why we did the session bus the way it is now.)

So if you want to support both, then just have the more limited
guarantees of the current bus... add to them the rule that there's
just one X server (at a time, I guess), and that there's no remote tcp
access... done? Now the OS can merge new logins to an existing
session, or not, whatever. Correct usage of dbus won't care.

Alternatively, I think, you'd declare multiple sessions on the same
host same user to be off-limits and permanently unsupported.

Havoc