per-user dbus

[Ray Strode]

Hi,

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.

What might make sense is having a way for programs to add themselve to
the session without their parent being in the session.  I could
imagine, if DBUS_SESSION_BUS_ADDRESS wasn't set, looking for the first
available running session bus for the user (how? kernel keyring? X
property?) and joining it.  This would solve the
cron-can't-access-my-session-even-when-i'm-logged-in problem.
Although, I think that problem would better be solved by
gnome-settings-daemon or some other session daemon just providing cron
like functionality.

I do think the number of cases where a user bus is useful is pretty
small.  I'm not saying those cases are invalid, but we shouldn't try
to shoehorn other cases into the user bus bucket.

--Ray