Object paths naming conventions?

[Marcel Holtmann]

Hi Matt,

> > >> > However, what I thought I was trying to convey is NOT that "/" (or
> > >> > any other path) is now owned globally by org.bluez, but that it must
> > >> > be unique within org.bluez  Is that correct?
> > >>
> > >> "/" would have to be available within a process implementing the bluez
> > >> spec. If two specs both use "/" (we just saw two in this thread), then
> > >> a process will not be able to use both of those specs. For the case of
> > >> bluez and that media player spec, using both seems unlikely. But it's
> > >> pretty easy to imagine specs that _are_ useful to use together.
> > >
> > >this is wrong. They can exists perfectly together if the interfaces have
> > >a proper namespace.
> > 
> > That's correct, in theory.
> > 
> > In practice, most bindings don't let you register interfaces only. You 
> > have to register the entire object.
> > 
> > So if two different and unrelated codepaths need to use the / object, only 
> > one will succeed.
> > 
> 
> And, I would contend, that this is correct. There is and always has been
> a difference between what the wire protocol will allow (things like
> variable return types spring to mind) and what the common object mapping
> layer allows.
> 
> DBus is an object model. This very strongly applies that each object
> path corresponds to a single implementation object. This object may have
> multiple interfaces, possibly with different implementations of the same
> method name under different interfaces, but one object nonetheless.

and what is the different between one object implement multiple
interfaces and two interfaces sharing the same object path?

> If you are expecting to have a single application implement one object
> which implements both specs then yes (although this may be awkward in
> some languages, eg java, where the method signature is assumed to be unique,
> even over multiple interfaces), however, if you are expecting to have
> separate libraries with separate objects both in the same process and
> registering the same path, then I contend that this should not work.

That is a pure technical issue that some bindings are broken.

Regards

Marcel