aKademy 2006: QtDBus and interoperability

After the Keynote from Aaron to start the day, the first talk i attended was the talk from Thiago Maciera. He works at Trolltech and brought us the QtDBus bindings in Qt 4.2.
(unfortunatly i forgot to take some photos...)
The subtitle of the talk was: "How You Can Use D-Bus to Achieve Interoperability"
Here is what i wrote down while he talked:

He talks about what interoperability is: Two different sofwares working together
This talk is mainly about inter-process interoperability.

D-Bus is an Inter-Process Comunication / Remote Procedure (IPC/RPC) system defined by freedesktop.org

"D-Bus is a message bus system, a simple way for application to talk to one another"

(citation from freedesktop.org)
D-Bus works like a star formation with one deamon in the middle connecting the different applications together.

He explains what interoperability is good for: another method to access your technology. This brings: broader user-base, less resource usage on the system because of reuse, good PR because you are the nice guy :-)

But even if your application has no distinctive features, then interoperability provides you the ability to access other applications features etc.!

Interoperability example:
The Desktop API (DAPI)
Allows to access desktop functionality like sending email, turning on/off screensavers, opening urls etc.
DAPI consists of two components: A daemon and a library that links to the application.

To use this (interoperability) you have to define an API, and define a format for the information exchange.

First solution: write a library

Has positive (fast, little modification) and negative (if you use c++ you are tight to it, if you use Qt and KDE the other have to use it also, scripting languages have problems using the library) aspects.

Second solution: write an external application

(Like xdg-utils)
No problem with linking, easy access from any language or shell
Requires re-parsing of data, performance penalty of starting new processes every time

Third solution: socket, pipe or another raw IPC system

Solves the problem with linking, no penaltiy with process starting, easy to access from any language.
But: requires establishing and testing the new protocol, requires the protocol to be established on each participant, difficult to add improvements, difficult to access from shell scripts.

Fourth solution: other IPC/RPC systems

Instead of defining own IPC/RPC system, use existing solutions like DCOP
No problem with linking, no penalty with process starting, easy to connect from any language, command-line access tool is possible.
But: access from any language is limited by the availabliity of implementations, DCOP suffers form forward compatibility and is hard to extend.

Final solution: D-Bus

Has been modelled after DCOP and so has all of its benifits.
In addition:

• It has been designed with forward compatibility with future extensions in mind
• Many bindings already available: glib, Mono, Python, Perl, Java
• Works on all platforms KDE supports (work on Windows ongoing)
• Best of all: it is nativiely supported by Qt and KDE
• its the IPC/RPC system that we chose to replace DCOP
• its beend designed to replace DCOP (concepts are very similar)
• it integrates nicely with the Qt Meta Object and Meta Type Systems

To use it, you have not much to do. The KDE buildsystem (CMake) can output the code for you, needed to use it.

To export functionality:

• exporting from QObject derived classes is easy, allowing any slot to be called on it
• better ist to use a class derived from QDBusAbstractAdaptor which just exports the functionality you want to export
• process XML definition of an interface into a C++ class derived from QDBusAbstractAdaptor (this way you can easily implement an interface from third parties)