Object paths naming conventions?

Havoc Pennington hp at pobox.com
Fri Jul 18 09:58:07 PDT 2008


On Fri, Jul 18, 2008 at 12:46 PM, Marcel Holtmann <marcel at holtmann.org> wrote:
> Your point is that every API contract should use namespacing of object
> paths to allow multiple APIs in one process. And I agree that is a nice
> feature to have. However my point is that namespacing the object path is
> not needed since we do have namespaces within the interface names in all
> cases that I have seen so far.

How does a namespace on the interface prevent collisions on instances?

> From the client point of view and thus the language binding actually
> using the API, I think the language object you always refer to is
> represented by the object path + interface name. Feel free to correct me
> here, but that is my experience.
> So why do we need namespaces in the object path and the interfaces. What
> kind of benefit does it give us?

The problem is that in say Java or C++, you don't want the object at
"/" to be like:

 class DoEverything implements SessionManager, Accessible,
Application, Foo, Bar Baz {
    // insert giant boatload of methods here

You want separate objects and code modules for the different functions.


More information about the dbus mailing list