D-Bus User Bus
mzqohf at 0pointer.de
Wed May 19 19:15:12 PDT 2010
On Wed, 19.05.10 15:30, Havoc Pennington (hp at pobox.com) wrote:
> On Wed, May 19, 2010 at 2:18 PM, Thiago Macieira <thiago at kde.org> wrote:
> > Another way to look at this is to have only a user bus, but introduce a
> > session or domain concept inside it. Connections in one domain can only see
> > connections in that domain, plus the global domain. Access to a domain is
> > granted by knowing the domain's "secret" at connection time (like an ID at
> > handshake or by connecting to a special Unix socket whose name is random and
> > is saved in an environment variable).
> This is almost equivalent to sticking the display name at the end of
> bus names in terms of effect, but more transparent to apps...
> The bus name flags stuff is extensible so it might be:
> * the bus is a per-(user,machine) bus
> * inside the bus, mark most bus names as per-session with a session
> ID associated with them
> * associate each connection to the bus with a session ID
> * names are per-session by default unless an ACROSS_ALL_SESSIONS flag
> is set when taking name ownership
> * filter out names from other sessions when listing names, etc.
Well, this approach has the same effect of what I was
suggesting. However, while I suggested the appending of the display ID
should happen on the client side (and in the gtk app class) this
approach would move that down into the bus.
To my it appears as if this logic is more appropriately placed in gtk
than in dbus itself though.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus