Object paths naming conventions?

Marcel Holtmann marcel at holtmann.org
Fri Jul 18 09:14:40 PDT 2008

Hi Havoc,

> > this is actually wrong. Two independent specifications can perfectly
> > share one object path. The namespacing of the interfaces is here the
> > important bit.
> I wrote the spec, the library, and the daemon, so I think I know what
> they are about. Yes, you can dynamically switch on interface and then
> route the message to different objects. No, that is not how it's
> intended to work nor is it how libdbus is set up to work nor is it how
> most bindings work nor does it make any sense.

so you are putting a strong meaning/representation on the object path. I
really don't. As mentioned it is a means to end and yes, it is necessary
and an important part of the D-Bus model, but for me not as important as
the interfaces.

If I look from an API perspective (client view), then the object path is
less interesting. I fully agree that from an implementation point of
view inside the server, the object path has a more relevance since it
defines internal structures. Neverless we have experienced that
attaching user_data to an object path gives us no benefit. We actually
do attach the user_data now to interfaces. Since an object path without
interface is useless and we always have at least one interface.

The libdbus has actually two ways to interact with the message bus. One
is the filters and the other is the object handlers. So for bindings or
helper libraries they are free to use what suits them best. And not
using libdbus at all (like the Mono or Java bindings) is also fine.

> > I can see a point that some bindings are limited in how to express
> > multiple interfaces on one object path and separate this, but that is
> > really an issue of the binding and not the D-Bus API that we trying to
> > expose. And if the bindings are limited, then the bindings are broken.
> dbus is set up to encourage a particular kind of mapping to language
> bindings, and that mapping is that a language object goes at an object
> path.

I might be totally missing something here, but please show me where it
the pure object path and not object path + interface that actually
defines the language object.



More information about the dbus mailing list