Object paths naming conventions?

[Havoc Pennington]

This is a great explanation - I think of it the same way, in terms of
low vs. high level and the "SHOULD" or recommended object system
mapping.

Havoc

On Fri, Jul 18, 2008 at 2:48 PM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> 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
>