Object paths naming conventions?

Marcel Holtmann marcel at holtmann.org
Fri Jul 18 09:55:39 PDT 2008


Hi Havoc,

> > My point is that the actual meaning (name) of the object path is
> > irrelevant and it is not needed to tie this to the interface/API
> > contract. And thus the namespacing of object paths becomes irrelevant.
> 
> It depends. If a spec says "the singleton is at /foo/bar" then it's in
> the API contract. If the spec says "call method xyz to get the object
> path," then yes a spec like that allows you to generate an object path
> on the fly and return it (and also requires an extra round trip, which
> is the tradeoff).

to keep up your singleton argument. The object /foo/bar can be a
singleton for interface bar.A and also foo.A.

What is an object path without an interface good for?

> But even if you generate object paths on the fly, you should use a
> scheme that avoids collisions. You can use a mktemp-like scheme of
> generating random strings, or namespacing, or whatever. It won't work
> or make sense to generate "/" as the name of every object.
> 
> Anyway, you're right the object path is just an arbitrary string and
> can be anything; but, it needs to be a unique string for each distinct
> object. So that means either random/guid type strings (like mktemp or
> uuid), or namespaced strings, or guids inside a namespace is another
> common pattern (like /org/foo/{guid}).

We do have to generate some uniqueness inside parts (don't wanna use the
word directory here) of hierarchy if the same interface is used (based
on MAC addresses or anything else that is unique in that context).
However that uniqueness doesn't have to span across different
interfaces. So for example we can have:

	/org/foo with org.foo.A
	/org/foo with org.foo.B

and

	/org/bar with org.foo.A

Since org.foo.B is present on one object with org.foo.A it doesn't mean
it has to be present on /org/bar only because the other one is present.

So the object path + interface name represents to me an unique instance
where I can have method calls on. With a different interface name, but
the same object path is becomes a total different instance.

Regards

Marcel




More information about the dbus mailing list