Object paths naming conventions?

[Marcel Holtmann]

Hi Havoc,

> Another important point here. The find-object-by-interface hack only
> works for _singletons_. Not all object instances are singletons. A
> special case find-singleton-by-interface behavior is maybe nice to
> have, but it's a special case. What you really want, if allowing
> find-singleton-by-interface, is to not specify an object path at
> all... to just have the message contain an interface, and then
> dynamically find the object from the interface. dbus won't allow this,
> but if we did allow it, the right way would be to allow omitting the
> object path, rather than having everyone use a conflicting object
> path.
> 
> I think what's "meant" by using "/" as the object path is "I don't
> want to have an object path in the message, find me the singleton
> implementing this interface" - but, that just doesn't work with the
> current spec. "/" is not the same as leaving the object path out -
> it's like using an arbitrary pointer when you mean NULL. If you want
> to ignore the object path and just switch on interface, it would be
> better to use something like /org/bluez/everything as the object path.
> 
> Otherwise you're interfering with the non-singleton case, which
> clearly does _require_ the object path, since it can't be deduced from
> the interface.

it is pretty clear we are talking about two different things here. Just
to make this perfectly clear. I am _NOT_ talking about omitting the
object path by using / as object path for everything. I am also not
talking about singletons. And I know what the object path is for and why
it is there.

Your point is that every API contract should use namespacing of object
paths to allow multiple APIs in one process. And I agree that is a nice
feature to have. However my point is that namespacing the object path is
not needed since we do have namespaces within the interface names in all
cases that I have seen so far.

And my point further is that multiple (and different) interfaces can use
the same object path without interference.

>From the client point of view and thus the language binding actually
using the API, I think the language object you always refer to is
represented by the object path + interface name. Feel free to correct me
here, but that is my experience.

So why do we need namespaces in the object path and the interfaces. What
kind of benefit does it give us?

Regards

Marcel