/org/freedesktop/DBus/Local in message header causes disconnect - why?!

[Havoc Pennington]

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 
package.

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 
correctness.

I would think of it as: the "Local" names are reserved for synthetic 
messages that never leave the local address space of an implementation.

Havoc