Object paths naming conventions?

[Thiago Macieira]

Marcel Holtmann wrote:
>> DBus is an object model. This very strongly applies that each object
>> path corresponds to a single implementation object. This object may
>> have multiple interfaces, possibly with different implementations of
>> the same method name under different interfaces, but one object
>> nonetheless.
>
>and what is the different between one object implement multiple
>interfaces and two interfaces sharing the same object path?

The difference is semantics.

The object path should convey a meaning by itself. The interfaces in the 
object path are simply the communication method, the way both client and 
server know how to interpret the calls, replies and values.

But, in the end, you should still have the concept of "object". It doesn't 
make sense to have two completely unrelated interfaces in the same 
object.

>> If you are expecting to have a single application implement one object
>> which implements both specs then yes (although this may be awkward in
>> some languages, eg java, where the method signature is assumed to be
>> unique, even over multiple interfaces), however, if you are expecting
>> to have separate libraries with separate objects both in the same
>> process and registering the same path, then I contend that this should
>> not work.
>
>That is a pure technical issue that some bindings are broken.

You've got three binding authors/maintainers here telling you they don't 
believe so (three of the largest, most used bindings, if not the three 
most).

The point I'm trying to make is that the object path has a meaning. 
Different meanings should have different object paths. So it's ok to call 
your object "/MainWindow" if it represents the main window, even if that 
comes from a library, not the application's own code. However, it's not 
ok to call your object "/MainWindow" if you're exposing interfaces that 
control disk storage.

Also, mind you: the BlueZ daemon *can* use / and /hci0 and whatever it 
wants. What it can't do is request that applications that want to 
interact with BlueZ also use those object paths.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080718/a1f7b9a3/attachment-0001.pgp