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.

Europe trip

Here Im in Germany, Stuttgart to be more precise, for BlueZ meeting and UPF. Meeting already started and we will probably make the notes available here: http://www.bluez.org/development/. I will comment about the meeting latter on when I got some time.

UPF will be starting next week, oct 4th to 8th, and since this is my first time attending to such event I think there will be a lot of things to blog about, and finally after all the fun with bluetooth/BlueZ I will be heading to Amsterdam for the Maemo Summit where I will be participating on the BlueZ bof.

Thats it for today :D

Bossa '10: Call for Presentation

For those interested in presenting something at bossa conference please follow this guidelines:

http://bossaconference.indt.org/programme/speakers-list

GSoC 2009

BlueZ was accepted as a organization in 2009 and granted with 6 slots (+1) on GSoC, we got a total of 37 proposals where just 2 were considered ineligible, and here are the projects as well as the students which will take part of program this year:

Student: Claudiu Coman
Mentors: Vinicius Gomes
Title: Generic HID

The idea is similar to remoko, which was part of last year GSoC program under openmoko organization, but aiming to be more generic and done as a plugin to bluetoothd.

Student: João Paulo Rechi Vita
Mentor: me
Title: A2DP Sink Role

Joao is back, he did the PulseAudio integration with bluez audio subsystem, but this time doing some work on the bluetoothd but not restrict to it since we want the plugins (alsa, PulseAudio and eventually gstreamer) too. Most of the code for avdtp/a2dp is already done so just small changes are really needed on bluetoothd, now for the plugins is a completely different story since the receiver can be a lot more complicated then the sender and sbc decoder is not as tested as the encoder.

Student: Gustavo Padovan
Mentor: Marcel Holtmann
Title: L2CAP Enhanced Retransmission Support

Marcel himself is going to mentor Gustavo which already started doing some code for either kernel and userspace. This is an optional L2CAP feature, that allows more control of the Error Rate and more information about the data flow, very useful for audio streaming.

Student: MO Faruque Sarker
Mentor: Claudio Takahasi
Title: A One-Step Bluetooth Device Setup Wizard Using 2D Data-matrix symbol

Very interesting and promising idea, very suitable for smart phones where cameras are very common. It can probably be used (or reuse) for other stuffs like cable association, so the devices doesn't need to stay on discoverable mode to be paired.

Student: Nehul Malhotra
Mentor: Claudio Takahasi
Title: SIM Access Client

SIM Access profile is one of the few profiles BlueZ has no support so far.

Student: Yasir Khan
Mentor: Vinicius Gomes
Title: Wireshark live capture integration

The idea is to have Wireshark fully replacing hcidump so we can really make use of wireshark for development.

Congratulations to all students.

Bossa Conference ‘09

Bossa '09 was great, a lot of good old faces around but also some new 'troll' faces. For those that missed any presentation we plan to make them available here or subscribe to the RSS feed here.

Here are some of the available presentation that I recommend:

Elementary – small, scaleable touchscreen widget set for mobile devices - Rasterman


Making videoconferencing easy, also in your application - Olivier Crete


The future of Qt - Thiago Macieira