Object paths naming conventions?

Havoc Pennington hp at pobox.com
Thu Jul 17 14:33:45 PDT 2008


On Thu, Jul 17, 2008 at 5:16 PM, David Stockwell
<dstockwell at frequency-one.com> wrote:
> AFAIK there is no preferred way for using Object Paths, as long as they
> are unique within the namespace defined by your well-known connection
> name ("org.fifthplanet.gogglesmm").

This is wrong. The bus name is the name of a *process* not a
particular API exported by the process. All objects in the process can
be reached through *any* of the bus names owned by the process. Using
object path "/" is the equivalent of specifying a shared lib with a
global object "extern Object *o;" or something like that, and claiming
that because the library is called "libbluez" then that has namespaced
the global symbol "o". It has not.

The caller has to specify both bus name and object path because it's
first specifying how to get to the process, then how to get to an
object inside the process. These may look redundant, but they are not,
because those two namespaces are dividing up two different things (all
processes on the bus, vs. all objects inside a process)

It's exacly the way specifying "-lbluez" at compile time and then
calling a function "bluez_whatever()" is not redundant.

> In fact, the BlueZ group (well-known name: "org.bluez") recently moved
> from longer names like/org/bluez/hci0 to /hci0 for one object path,
> because the "/org/bluez" prefix really conveyed no additional
> information.

This is wrong - the /org/bluez DOES convey additional info, and bluez
is now broken. At least, unless the bluez spec requires that a process
exporting the bluez API does not export any other APIs on the same
connection. (Which is a terrible idea IMO; no matter what the process
is, conceivably it could want to export APIs for things like allowing
admins to shut it down, or session management, or monitoring, or other
generic things all processes might want to support. Or it's a
legitimate implementation of the spec to put multiple functions in the
same daemon - why not allow that?)


More information about the dbus mailing list