Object paths naming conventions?
simon.mcvittie at collabora.co.uk
Fri Jul 18 11:48:34 PDT 2008
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
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.
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080718/5b2c6526/attachment.pgp
More information about the dbus