Object paths naming conventions?

[Matthew Johnson]

On Fri Jul 18 12:30, Thiago Macieira wrote:
> Marcel Holtmann wrote:
> >Hi Havoc,
> >
> >> > 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?
> >>
> >> "/" would have to be available within a process implementing the bluez
> >> spec. If two specs both use "/" (we just saw two in this thread), then
> >> a process will not be able to use both of those specs. For the case of
> >> bluez and that media player spec, using both seems unlikely. But it's
> >> pretty easy to imagine specs that _are_ useful to use together.
> >
> >this is wrong. They can exists perfectly together if the interfaces have
> >a proper namespace.
> 
> That's correct, in theory.
> 
> In practice, most bindings don't let you register interfaces only. You 
> have to register the entire object.
> 
> So if two different and unrelated codepaths need to use the / object, only 
> one will succeed.
> 

And, I would contend, that this is correct. There is and always has been
a difference between what the wire protocol will allow (things like
variable return types spring to mind) and what the common object mapping
layer allows.

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.

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.

Matt

-- 
www.matthew.ath.cx
D-Bus Java
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080718/37ccc354/attachment-0001.pgp