register object path + introspection

Havoc Pennington hp at
Fri Jul 16 12:35:02 PDT 2010


2010/7/16 Rémi Denis-Courmont <remi at>:
> I wonder what "proper" means here. In my understanding, method calls should
> be sent "to" well-known names directly. In other words, clients should NOT
> resolve the well-known names to unique names as this would be obviously
> race-prone.


If your API is at all stateful you need to use unique names, imo. The
race is that if the well-known name changes owner, you may send some
calls to the old owner (hopefully handling the errors, if the old
owner has exited). However, for a stateful API that race is a better
situation than sending some calls to the old and some to the new, with
no errors.

In a stateless API you could stick to the well-known name instead.

> So what you mean but are not stating clearly (to me) is that signal
> subscriber really need to check both the sender name _and_ the object path.
> In other words, an ambiguity occurs if a single process provides two
> services with the same interface but different well-known names. Then
> signals from those two services would have identical (unique) senders and
> interface fields, leaving only the object path to discriminate them.
> Correct?

The word "service" is not in the spec much because it's confusing.
Here it sounds like you mean "object"

If you mean an object, then yes, if you want to know which object a
signal is from you need to look at the object path.

If you're familiar with Java or similar languages,
 dbus interface = java interface
 dbus object path = java object
 dbus bus name = a way to locate a java app process and send it messages

A signal subscriber that wants to get signals from a particular object
inside the remote process, needs to look at the sender (to see which
process) and the object path (to see which object).

> Then given generic interfaces such as D-Bus introspection, any process with
> potentially more than one service needs to use name spaces for its object
> path. Correct?

Any process with potentially more than one object will need to name at
least one of the objects something besides "/"

> So MPRIS sucks but oFono not?

I haven't looked at oFono (or MPRIS either but people have said it
uses "/" and that part is wrong if true)

> I don't see why the bus would have had to know the objects. The bus could
> have the "authenticated" sender headers and left them as is. Then if
> services always set the sender name, object path could have been scoped by
> bus name. In theory I don't see the problem. Race condition??

What I was suggesting is that we could eliminate the separate concept
of object path, and only have bus names, if we wanted to register all
objects with their own bus name.

I suppose your design would also be possible, to have multiple object
trees each one rooted to a particular bus name. The idea would be to
hide processes (connections) I suppose. You'd probably want to just
drop the unique bus names in this case.

However, the way it actually works isn't either of these.... the bus
name is a routing-only construct, with all names owned by a process
exporting the same process with the same objects and the same


More information about the dbus mailing list