Object paths naming conventions?

[Marcel Holtmann]

Hi Havoc,

> > AFAIK there is no preferred way for using Object Paths, as long as they
> > are unique within the namespace defined by your well-known connection
> > name ("org.fifthplanet.gogglesmm").
> 
> This is wrong. The bus name is the name of a *process* not a
> particular API exported by the process. All objects in the process can
> be reached through *any* of the bus names owned by the process. Using
> object path "/" is the equivalent of specifying a shared lib with a
> global object "extern Object *o;" or something like that, and claiming
> that because the library is called "libbluez" then that has namespaced
> the global symbol "o". It has not.
> 
> The caller has to specify both bus name and object path because it's
> first specifying how to get to the process, then how to get to an
> object inside the process. These may look redundant, but they are not,
> because those two namespaces are dividing up two different things (all
> processes on the bus, vs. all objects inside a process)

the caller has to specify bus name, object path and interface. Yes, I
know that the interface in theory is optional, but nobody actually is
using this feature of D-Bus. And I can't remember any binding actually
allowing it.

> > In fact, the BlueZ group (well-known name: "org.bluez") recently moved
> > from longer names like/org/bluez/hci0 to /hci0 for one object path,
> > because the "/org/bluez" prefix really conveyed no additional
> > information.
> 
> This is wrong - the /org/bluez DOES convey additional info, and bluez
> is now broken. At least, unless the bluez spec requires that a process
> exporting the bluez API does not export any other APIs on the same
> connection. (Which is a terrible idea IMO; no matter what the process
> is, conceivably it could want to export APIs for things like allowing
> admins to shut it down, or session management, or monitoring, or other
> generic things all processes might want to support. Or it's a
> legitimate implementation of the spec to put multiple functions in the
> same daemon - why not allow that?)

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. Actually for introspection purposes, I think
it is even bad that we don't start from the root path.

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.

Regards

Marcel