Object paths naming conventions?

[Havoc Pennington]

Hi,

On Thu, Jul 17, 2008 at 6:27 PM, Marcel Holtmann <marcel at holtmann.org> wrote:
> 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.

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

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.

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

(If you put an object at '/' - or any other node really, but
especially '/' - it's important btw to call
dbus_connection_list_registered() to get child nodes and incorporate
them into your Introspect() implementation.)

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

Havoc