/org/freedesktop/DBus/Local in message header causes disconnect
hp at redhat.com
Wed Feb 21 18:56:32 PST 2007
Simon McVittie wrote:
> On the other hand, the namespace of object paths is local to the service,
> which is perfectly within its rights to use paths like /docs/123 - I'd
> understood the namespacing in object-path-space to be necessary only for
> the case where the same bus connection is shared by e.g. multiple libraries?
Sharing the same connection between all code in the same process is
intended to be the normal case; most usage of private connections that
I've heard about was due to working around bugs in libdbus. I would
certainly consider it a bug in libdbus if typical apps needed multiple
connections, because it just isn't a good idea if every app has a bunch
of separate bus connections open. (It's significantly wasteful, and much
less importantly, encourages race conditions since there's no ordering
between messages on different connections.)
It should be safe for any *app* (but no libraries) to use paths without
a domain name prefix, just as you can write Java classes in the default
An app doing this though should probably avoid paths starting with a
toplevel domain (/org/, /com/, /net/, /gov/, /au/, etc.) There are
enough country codes and other TLDs that worrying about it is probably
more annoying than just sucking it up and using a domain name prefix.
However you feel about this, using /org/freedesktop/DBus paths in an app
is almost certainly a bad idea.
> "Broken applications that don't check the sender can believe they have
> been disconnected when in fact they haven't" sounds to me like a bug in
> those applications - depends on your point of view I suppose.
the "Local" messages are really part of the libdbus API, not the
protocol. So apps using libdbus should be able to rely on the API's
I would think of it as: the "Local" names are reserved for synthetic
messages that never leave the local address space of an implementation.
More information about the dbus