per-user dbus

[Havoc Pennington]

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.

> DBUS_BUS_USER_MACHINE is nothing that would *fix* the network synchronization
> issues that a configuration system on top of a shared FS has, but it
> would ameliorate it at least for local sessions.

That's the whole problem. The amelioration means now you have a
different code path for two sessions on one machine (which isn't that
useful anyway) and two sessions on different machines (widely used in
large linux deployments). The two sessions on different machines case
then breaks. People do just as you just suggested, they say "well
per-user,machine sounds better, since at least it's shared on one
machine" but that isn't a solution at all - it only helps in a case
that is largely useless.

We did try this before; bonobo was per-(user,machine) by default.
Before that, we had a per-display service locator ("GNORBA") which
also worked better than the per-(user,machine) setup. And KDE worked
better. Empirically, the per-session designs have worked better.

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.

Havoc