mzqohf at 0pointer.de
Fri Nov 13 14:47:50 PST 2009
On Wed, 11.11.09 09:51, Ray Strode (halfline at gmail.com) wrote:
> On Tue, Nov 10, 2009 at 10:37 AM, Colin Walters <walters at verbum.org> wrote:
> > On Mon, Nov 9, 2009 at 5:16 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> >> While some folks seem not to particularly like the idea (Hey, Colin!)
> > Well, it's not that I don't like the idea of a per-(kernel,uid) bus,
> > it's more that I think that's what the "session" bus should be.
> > In other words, if we have _USER, what should still be using _SESSION?
> The session bus serves a very useful purpose, it defines the scope of
> the user's session. I think that was one of it's original design
> intents (right Havoc?).
> There are various bits of infrasture that hook themselves to the
> lifecycle of the bus because they expect that the bus will only
> survive for the duration of the user's session.
> I don't think we can break that gaurantee.
> Having a separate user bus may make sense for limited number of cases,
> but i don't think it makes sense to replace the session bus with a
> user bus.
I don't think the number of cases is really that small. A number of
user services are bound to the local hardware or the local machine in
one way or the other. PulseAudio is one example: PA manages audio
devices and all local user sessions should get access to all
accessible audio devices.
But even more important are the various network services we run these
days with user priviliges. All the gnome-user-shares, rygels, obexds
of this world. The fact that these services are currently bound to a
user session to be around is fundamentally broken (right, davidz?). If
you want to serve files via WebDAV, Bluetooth or UPnP A/V you should
not have to be logged in.
Also, there are those services that provide access to user databases,
such as the keyring or e-d-s. Ideally there would only be one daemon
instance around of these for each $HOME across the entire
network. However that is unrealistic (see my other mail, why) and
would be unreliable too, so it cannot be done. The next best thing for
these services would be the (user|machine) bus, which has the
advantage that sessions on different machines might still step on each
others toes but at least multiple local sessions won't.
So yes, there are many cases I believe where the (user|machine) bus
would be preferable over the session bus, possibly even more than the
other way round.
That said, I am against replacing the session by a user bus, too -- I
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus