DBus API x DBus Specification

With the BlueZ meeting over and the suggestion made by the developers it seems we had made some very good decisions while designing the BlueZ 4.x. There has been some talks regarding this before, specially regarding round trips which have a very bad impact in performance, but I never really saw anyone commenting about using DBus as the only API. So how different it is to design a Specification to an API? Well lets start with a Specification:

DBus Specification

It is almost as defining a protocol over DBus, so its documentation normally define the data types, how they should be interpreted and so on. This directly reflect both in the server and in the client code, since the specification may define its own data types this is no longer only about DBus, but sometimes a real stack over it (see telepathy or NetworkManager).

Pros:

- Easy to adapt, specially when the applications involved share the same libraries.
- Very efficient, it doesn't depend on DBus 'native' types it is easy to avoid round trips and heavy use of bus.

Cons:

- Very hard to test and document, introspection may become meaningless in some cases.
- Extra build time dependencies may be required
- The more heterogeneous are the applications the worse it will be to maintain.

DBus API

It is almost the opposite, it only uses DBus native data types, so the introspection data is normally enough to the developer to understand how to use the API (or not :D). As opposed to an specification the documentation might be very simple, actually this seems quite natural to me as one can use d-feet to explore it became quite easy to understand and test.

Pros:

- Easy to test and document
- No extra build time dependency
- When done right can make use of args in matching rules

Cons:

- Not so efficient as it may require some extra round trips or signals.

As you can see DBus can be used in very different ways, while an API is probably more suitable for system daemons, where the use of complex data types makes it difficult to became adopted by the various languages/toolkit as it may generate language/toolkit specific bindings where the maintenance become a nightmare, in the other hand a specification may fits the needs of applications that want to exchange very specific data where the applications interested in the data are probably part of the same package/solution and share the same dependencies/libraries.