Object paths naming conventions?

[Marcel Holtmann]

Hi Thiago,

> >> > 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 think that is a bug within the bindings. The bindings job should
be actually abstract from this usage and make it possible for two
unrelated codepaths to register interfaces on the same object path.

In BlueZ we actually allow plugins to register additional interface on
top of an already established object path. This makes it easy to extend
everything with lets say a debug interface. The codepaths are unrelated
and we can have a nice separation inside the core and not bloat it if
this extra functionality is not desired.

Regards

Marcel