Object paths naming conventions?

[Marcel Holtmann]

Hi Havoc,

> > I can see where you are coming from, but this namespacing of object
> > paths or not makes no difference whatsoever. The important part is that
> > the interface names have a clean namespace.
> >
> > Yes, sure it would be nice to get clean separated object trees, but it
> > really gives us no benefit.
> 
> This is not accurate in general. Maybe in the specific case of bluez
> it happens to be fine, because you only care about one implementation,
> or because of other bluez-specific factors, I don't know. I'm not
> trying to tell you how to do bluez. What I do care about is making
> clear that people reading the thread should not, in general, be doing
> this. Especially for any spec we'd expect a desktop app or something
> like that to implement.
> 
> The bottom line reason is that all "no namespaces" specs are mutually
> exclusive. If we had a session management spec, an a11y spec, and a
> media player spec, then it's very much expected that one app will
> implement all three. So if they fight over "/", stuff will just break.
> It is a benefit to make this work.

this is actually wrong. Two independent specifications can perfectly
share one object path. The namespacing of the interfaces is here the
important bit.

While I acknowledge that some bindings might have problems in this area,
but that is really an issue of the bindings. From the D-Bus spec. and
from a technical point of view it is fine if two APIs share the root
object path /.

> Even for a system daemon, I would think there's no reason to preclude
> putting multiple specs in the same daemon, even if that's not
> currently done. There are enough daemons floating around that I can
> see people wanting to say combine some of them into one process, or
> say wanting to invent specs that all of them implement, maybe for
> start/stop/reload controls or something. There are plenty of plausible
> scenarios where there's a benefit.
> 
> The interface is, again, not the same thing. You need a separate
> namespace for each universe of items that can have name collisions.
> Object instances (which is what a path refers to) are not in the same
> universe of items as object types (which is what an interface refers
> to).

I disagree here.

> Keeping my shared library example, if you namespace the type as
> Gtk::Widget, that does not mean you can use the same pointer or same
> global variable name for two different widget instances. You need to
> name your two instances something different.
> 
> What happens more commonly with dbus, when people are using global
> singletons, is that you have two instances with different types (=
> dbus interface), and you need to be sure they are not sharing the same
> global variable name (= dbus object path).
> 
> People have been consistently confused about the difference between
> bus name, interface, and object path, so I want to be sure we're
> always very clear on why they are not redundant and what they are.

The difference are pretty clear and that is not the question here. You
are arguing for a necessary namespacing of object paths and I disagree
with the need for it. Object paths are similar to instances and we
should support instances with multiple interfaces. So if these
interfaces belong to different API spec. makes no real difference.

I can see a point that some bindings are limited in how to express
multiple interfaces on one object path and separate this, but that is
really an issue of the binding and not the D-Bus API that we trying to
expose. And if the bindings are limited, then the bindings are broken.

> > Actually for introspection purposes, I think
> > it is even bad that we don't start from the root path.
> 
> This shouldn't matter; DBusConnection should be creating a default
> Introspect() for any node in the path hierarchy without an object
> there, that lists child paths. This allows traversing all objects in
> the tree.

That is not what I meant. I meant that in most cases we need two extra
roundtrips to the message bus to get the root object.

> > So my point here is clearly that we either do namespacing within the
> > object paths or within the interface names. Using both is redundant and
> > I decided to use the interface names, because they are the API contract.
> > The object paths are dynamic instances and besides one root object (if
> > that be / or something else) it makes no difference what naming
> > convention they follow.
> 
> This is like saying it makes no difference if every shared library has
> a global singleton called "theSingleton"
> 
> It does not help if every shared library's theSingleton object has a
> different type (aka interface). In fact, that makes it worse.

You really put too much meaning into object paths. They are just a means
to an end to identify instances in a process. And yes, we do have to
think process here and not shared library.

I do actually think that every explicit registration of an object path
is total non-sense. Object paths should be registered/exist dynamically
depending on if an interface for that object path is present or not.

While doing API review an integration work of libgdbus into BlueZ, we
realized that we couldn't care less about object paths. There is only
one that is important, that is the root path (namespaced or not). It is
the only constant. All the other will be discovered via method calls and
thus it doesn't even matter what they are.

So from an application point of view, the actual object path becomes in
a lot of cases irrelevant. The application/daemon will register an
interface since that is what it cares about. The object path could be
random number. So if any other part in the application registers a
different interface with that random number, it will be still unique.
And that is what really counts.

My point is clearly that the combination of object path + interface must
be unique. All the rest is irrelevant and just bloat.

Regards

Marcel