D-Bus User Bus

[Lennart Poettering]

On Wed, 19.05.10 22:22, Havoc Pennington (hp at pobox.com) wrote:

> > To my it appears as if this logic is more appropriately placed in gtk
> > than in dbus itself though.
> 
> The difference is in the default. My suggestion is a way to get what
> you want, but while keeping the current ABI and protocol compatible,
> and per-session is the default unless something requests
> per-(user,machine)
> 
> The idea would be that extra work (multiple display handling) is
> opt-in instead of opt-out and existing apps don't break

Well, you say "existing apps would break". I'd say "existing apps would
cleanly tell the user that what he wants to do does not work".

Let's not forget that gdm currently makes it impossible to login twice
as the same user. If you do that the fast-user switching logic would
just activate the already existing X display. ANd that is good that
way. And that basically means that what you call "existing apps
breaking" is really really hard to reproduce on a normal Fedora
machine. And that's not much different on other Linuxes. (You'd have to
get rid of gdm, and start your multiple sessions with startx)

I really think it would be a good idea if that gtk app class would just
get a "concurrency level" param, which would be "UNIQUE_PER_DISPLAY",
"UNIQUE_PER_MACHINE", "UNIQUE_PER_NETWORK", and which would then handle
everything automatucally:

UNIQUE_PER_DISPLAY: the display suffix is appeneded to the bus name and
the NFS lock taken to avoid that other networked machiens can starte the
same app.

UNIQUE_PER_MACHINE: the display suffix is not appended, but the nfs lock
is taken, too.

UNIQUE_PER_NETWORK: the display suffix is not appended, and the nfs lock
isn't taken.

(where nfs lock is just some filename rename trick thing, not a posix lock)

Lennart

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