Joerg.Barfurth at Sun.COM
Mon Nov 16 07:18:42 PST 2009
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
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.
(+) 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/
More information about the dbus