per-user dbus

[Joerg Barfurth]

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

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

Yes. This is also echoed in Havoc's replies. Attempts to do that have 
failed, it probably won't work well.

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

Yes. But putting such services onto a per-user-machine bus may do more 
harm than good. Things seem to work in the environment in which many 
developers work (relatively standalone machine, possibly with multiple 
session/connections) but break in large end user deployments (where 
multiple sessions for a user typically occur on different machines.

Staying with a per-session bus forces developers to think about the 
scope of things they want to do that transcend a session.

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

For hardware that is per-seat, per-user-machine is also not the right 
model. Sessions provide the binding between a user and the seat (and 
thus the hardware).

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

This is especially true, if that session is on a different seat.

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

If these ttys are VTs on the same hardware (i.e. the same seat) that is 
a special case. I don't want the same to happen for sessions on 
different seats (if I play audio on my desktop, should that 
automatically be heard in the server room, where I still have a console 
open?)

OTOH, if a session migrates from one seat to another, I want sound from 
that session to follow the session.

I have to admit that defining the behavior of PA to be able to deal with 
both cases is difficult (+). But I don't believe that putting it all 
under a per-user structure and basing the design on the notion that 
there is only a single seat, is the right approach.

- Jörg

(+) When both happens in parallel, what should be the result:
Assume you have
1. SESSION_1 of USER is started on SEAT_1 and then detached
Sometime later you have
2a. SESSION_2 of USER is started on SEAT_1
2b. SESSION_1 of USER is reattached on SEAT_2

Where should audio started in (1.) be playing now?


-- 
Joerg Barfurth           phone: +49 40 23646662 / x66662
Software Engineer        mailto:joerg.barfurth at sun.com
Desktop Technology       http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/