User bus conclusion

[Lennart Poettering]

On Wed, 10.11.10 03:48, Ryan Lortie (desrt at desrt.ca) wrote:

> 
> On Tue, 2010-11-09 at 22:55 -0500, Havoc Pennington wrote:
> > I don't understand how a clear name is ridiculous.
> > DBUS_BUS_USER_ON_HOST seems pretty straightforward.
> 
> Fair.  Lennart?

I am fine with either name, but if we want to include some indicator
that this is machine-local in the name, then i'd go for USER_LOCAL or
LOCAL_USER.

> > 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?
> > 
> > From an app perspective nothing is really changing here, so there
> > shouldn't be API/cognitive churn. The main change is that now people
> > don't have to do their own locking for hardware-accessing services as
> > long as they know a particular user has claimed the hardware?
> 
> There is churn in any case.  Many existing users of the session bus
> assume that an X server is always running and that they can always
> launch graphical applications (telepathy launches empathy, some backend
> launches a password dialog, etc).

Also, we should emphasize sharing between multiple logins of the same
user, not isolating them. If you login via SSH you want to reuse the
passwords already stored in your keyring. And similar.

There's simply no point in seperating sessions, since it doesn't
actually work, and has no representation in the lower level
OS. i.e. user access is controlled by user, never by session.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.