Object paths naming conventions?

[David Stockwell]

Hello, Havoc,

> Hi,
>
> 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.
>

Thank you, I appreciate the clarification.  In a similar way, the 
objects can be reached by the well-known name, the unique connection 
name (e.g., :1.15); plus any additional well-known names the process may 
own.

However, what I thought I was trying to convey is NOT that "/" (or any 
other path) is now owned globally by org.bluez, but that it must be 
unique within org.bluez  Is that correct?

> 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?)
>

As far as BlueZ goes, I am (obviously) only a user and developing to 
their DBus API; I have *no* input to how they are naming things.  If you 
wish to take this up with Marcel & co...well, be my guest ;-)

Incidentally, it does appear (my experimentation) that DBus allows for 
some polymorphism in method calls (e.g., optional parameters).  Is this 
intentional?  It also appears that the some/most of bindings do not 
support this...

> Havoc

All the best, and thanks again,
David Stockwell