Object paths naming conventions?

[Marcel Holtmann]

Hi Matt,

> > 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.
> 
> I disagree strongly, I think the object model that DBus presents is that
> of registering _objects_, not interfaces. I think we have had
> discussions before that you should not expect the introspection data on
> an object to change without warning, to allow caching.

I consider this wishful thinking. Knowing everything up front is not
happening. Also object paths are registered are runtime and also
unregistered. They appear and disappear without warning, too.

> > 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.
>  
> Extend dynamically at runtime?

Yes.

> Implementation details aside, I don't think you should expect this to
> work.

It works perfectly fine. And even for the clients it is not a problem.
Either a method call gets answered or not. If they wanna check up-front
of the interface is available, then the clients can use introspection.

We do have the powerful libgdbus library that allows all of this with a
really simple API.

Regards

Marcel