per-user dbus

[Lennart Poettering]

On Wed, 11.11.09 16:24, Joerg Barfurth (Joerg.Barfurth at Sun.COM) wrote:

> >On the other hand, the only use case for having them actually be
> >separate that I can think of offhand is "poor man's virt" like xnest
> >testing.  And for the testing case, it's trivial to explicitly spawn a
> >separate bus when you want it.
> >
> 
> I don't think you should exclude the case of two graphical sessions.

Is there any current DE that would be able to deal with multiple
parallel logins? GNOME certainly is not...

> >>Also, I'd like to draw the distinction between session and user buses
> >>also in terms of network. I.e. i still believe we should try to make
> >>the session bus shared across the network, while the user bus is
> >>per-machine.
> >
> 
> If the optimal scope for a session bus is everything accessing the
> same X server, would the optimal scope for a user bus be everything
> accessing the same home directory - even if that is shared or
> replicated over the network?

That's a nice idea, however an unrealistic one I believe. It's just
too damn hard to establish some kind of communication channel between
all users of an NFS share in a reliable way.

NFS is unfortunately only a file system, not useful as a transport for
dbus. That means we'd always have to discover the dbus server some
other way, and it wouldn't even be clear which machine would have to
run the dbus bus daemon.

Having this would certainly be useful for servcies that provide access
to some database, such as the keyring, evolution-data-server and
suchlike. However because implementing this is not really possible I'd
simply forget about this kind of bus.

However, for user stuff that offers hardware control or network
services, i.e. gnome-user-share or PA, a bus that is shared between
machines is really unsuitable anyway.

> Maybe I don't really understand the use case yet. As for things
> mentioned in this thread:
> - keyring: I probably want to share my keyring as widely as my home
> directory. But I don't want to share an unlocked key access handle
> to my keyring beyond my current session.
> - PulseAudio: I don't see anything audio-specific that I want to
> have user-scope. Audio sources and sinks are generally associated
> with sessions, not users.

I disagree. For example if a user is logged in on tty1 and tty2 (being
Linux VCs) and changes between the two music you started on one tty
should certainly continue to play if you switch to the other.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4