per-user dbus

Lennart Poettering mzqohf at 0pointer.de
Fri Nov 13 16:32:19 PST 2009


On Fri, 13.11.09 18:38, Havoc Pennington (hp at pobox.com) wrote:

> 
> Hi,
> 
> On Fri, Nov 13, 2009 at 6:04 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> > I believe that a DBUS_BUS_USER_MACHINE would be a better place for a
> > config system than DBUS_BUS_SESSION, since -- as mentioned -- this
> > would make sure that at least multiple local sessions cannot step on
> > each others toes anymore.
> 
> The problem is that you simply need to design out the need to share
> the same bus, because you can't share it across machines.
> 
> I think dconf does this for example (with "last wins" semantics, but
> it does it). Though I haven't tracked dconf in a while, iirc it got
> this right.

desrt should probably respond to this, but i think his ideas are mostly
that if you have two dconf clients running on the same NFS shared home
dir you will lose notifications about changes but otherwise the last
access wins.

However, it would still be of benefit if notifications would continue to
work for two local clients if if they belong to two different
sessions.

It's a bit like inotify: inotify works fine on NFS between two processes
that sit on the same machine. It doesn't work across machines
however.

> I grant you, we haven't tried having both per-user,machine AND
> per-session available. So maybe people would get that right. But,
> please put the flashing lights on there. This per-user,machine bus
> does NOT mean you have one bus for all sessions, at all.

One thing is true, as well. Introducing a user|machine bus would *not*
make things worse than they currently are. 

Lennart

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


More information about the dbus mailing list