Missing user bus?

[Havoc Pennington]

On Sun, 2005-09-25 at 00:25 +0100, Robert McQueen wrote:
> 
> Basically I agree with everything you say, but I do think that from a
> technical point of view some (but not all) of what is on the session bus
> is definitely a per user and not a per session resource, such as
> backends storing information like configuration or address books (or
> even e-mails).

They _are_ conceptually per user. But using the _session_ bus for them
is right. Because to get true per-user you need the imap/ldap approach.
The "(user,machine)" bus is not more correct than a per-session bus. A
global-to-network bus like imap/ldap would be more correct, but I also
have no idea how to implement it.

The session bus works fine, in other words, and a (user,machine) bus is
not adding any user-visible benefit, and is adding stuff to confuse and
go wrong.

It's just a very powerful simplifying assumption for the desktop if
everything is per-session. Every time we've had per-(user,machine) (as
all the CORBA stuff was by default, and gconf) it broke a lot of things.
Multiple logins at once seem to never work properly because everyone
codes as if the stuff was per-session and nobody tests multiple login.

> Most IM systems only let you log in once, so these connections are
> definitely a persistent per-user resource, and many people want to be
> able to access them remotely or from a mobile device, see who's messaged
> them and send replies, view logs, etc. I fully anticipate that when we
> have some software out there, tech-savvy users (probably including
> myself) will hack up with a way of "stealing" their session bus and
> leave themselves logged in so they can run another IM client remotely,
> when what they really wanted was a per-user bus that allowed their
> connections to persist beyond their login.

You have a daemon implementing the service, right? Why not just have it
persist beyond login - you don't need a user bus to make your own daemon
persist I wouldn't think. You can use the system bus (perhaps with some
enhancements) to discover each new session and attach your persistent
daemon to it.

I'll repeat my warning that on timeshare systems admins will hate this
(and probably write a cron job to killall it, after reporting the bug).
I'm not sure designing for timeshare systems is right but be aware. (On
my personal system I just stay logged in all the time, so it wouldn't
come up...)

Havoc