register object path + introspection

[Havoc Pennington]

Hi,

2010/7/16 Rémi Denis-Courmont <remi at remlab.net>:
> 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.

See
https://bugs.freedesktop.org/show_bug.cgi?id=11454#c6

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"

http://dbus.freedesktop.org/doc/dbus-faq.html#service
http://www.freedesktop.org/wiki/Software/DBusAnalogy

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

Havoc