Object paths naming conventions?
marcel at holtmann.org
Fri Jul 18 08:52:05 PDT 2008
> > 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?
> Implementation details aside, I don't think you should expect this to
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.
More information about the dbus