Object paths naming conventions?

[Simon McVittie]

Another D-Bus binding maintainer (dbus-python, and I've also contributed
to dbus-glib) chiming in...

What you seem to be doing with BlueZ is to have an object model
that does not match the D-Bus object model, but is, however, also
implementable using the D-Bus low-level/message-passing model.

The D-Bus libraries and bindings are partly written in terms of the
message-passing model, and partly in terms of the high-level object
model. The high-level object model is the one we try to present to
application authors, because it's easier to understand. Some bindings
explicitly indicate the boundary, e.g. dbus-python has a "dbus.lowlevel"
which is in terms of messages, and ndesk-dbus (C#/.net) only exposes the
high-level part by default.

You can think of it as "MUST comply with the low-level model,
SHOULD also comply with the high-level model" if you like.

The D-Bus object model is that an object-path represents an object.
Objects can have many related or unrelated interfaces, but *it is the
same object*. Havoc frequently describes object paths as "analogous to a
C pointer".

So, if there exists some (conceptual or OOP) object that has all the
interfaces you want to put at the same object path, go for it.
Otherwise, no.

To put it another way: if you have an API that wants '/' to be a
com.example.FloorWax and another that wants '/' to be an
org.freedesktop.DessertTopping, the only way you can "legitimately"
implement both APIs (and in most bindings, the only way you can do so at
all) is by having an object that is simultaneously a floor wax and a
dessert topping :-)

Depending on the binding used, clients will have to jump through more or
fewer hoops to use services that don't follow the high-level object
model. Strongly and statically typed languages like Java are likely to be the
hardest here.

Service implementations that don't comply with the high-level object model
tend to be made more difficult (or even impossible) by many bindings, out of
a sense of "be conservative in what you emit (implement as a service) and
be lenient in what you receive (can deal with as a client)". Again,
strongly and statically typed languages like Java will have the most
difficulty with doing "unconventional" things.

    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080718/5b2c6526/attachment.pgp