DBusRAD

D-Bus usage best practices and rapid application development enablers research project

Telepathy IPC culture and infrastructure

During years of very much trial-and-error Telepathy framework development, we've made some fundamental practical discoveries on the subject of using D-Bus and inter-process communication in general, for building complex modular object-oriented desktop and mobile applications.

These innovations include, but are not limited to

Future directions

These discoveries have helped us make Telepathy successful numerous fields such as in the GNOME desktop (with Empathy and Gnome shell integration), in the One Laptop Per Child project and on Nokia phones (see e.g. Naba Kumar's and Mikhail Zabaluev's or Marco Barisione's presentation). There is still however lots of room for further Telepathy feature development, but implementing the aforementioned principles and patterns manually for the inter-component communication required by each new item of functionality has gotten tedious and repetitive as Telepathy has expanded.

The upstream GDBus library already implements a higher-level proxy construct complete with asynchronous method calls and rudimentary state caching. We should try to migrate the rest of our implementation support facilities, such as those based on marking some properties of objects as immutable, to GDBus and its code generator. We could also refactor some core Telepathy D-Bus communication around the ObjectManager interface which GDBus has native support for.

GDBus thus enhanced could serve as a basis for Telepathy in the future. This would enable us to have to worry less about the implementation of our IPC infrastructure, and instead focus on developing the actual user-visible features such as advances in VoIP/video calling support. But even more importantly, other projects could then benefit from our discoveries by utilizing the new GDBus functionality.

Knowledge dissemination

We feel that given the widely useful nature of our IPC usage principles, it is a shame how they have got stuck as an implementation detail of Telepathy. Some other projects (e.g. EU ACTORS, and MPRIS) have started using our IDL format and the low-level code generation tools, thankfully, but that's about it. We've also stumbled upon a lot of people hitting walls with their IPC based systems, e.g. due to impossible to solve deadlocking from trying to simulate synchronous local calling over D-Bus, or programming complexity insurmountable in growing systems from using too low-level message passing directly - which could've been avoided by understanding and adopting our principles and implementation helper mechanisms from the start.

In other words: we've learned valuable lessons during countless developer hours of tedious exploratory work on D-Bus API and wrapper library design. We don't want everybody else working on similar modular architectures to have to waste their time reinventing all this, but instead implement something new and useful which is also correct and efficient from the start.

Olli Salli is currently working on a Master's thesis which aims to put these underlying design and implementation principles of Telepathy into an academic context, linking them with bodies of research on object-oriented and distributed systems, and formalizing our extensions to, and applications of, existing concepts. However, as partially motivated above, we'd also like to

Projects which could benefit from sharing infrastructure with Telepathy

Some examples of related projects using D-Bus for IPC, where we believe redundant work would be avoided and functionality and quality in general improved by migrating to an enhanced common D-Bus infrastructure:

BlueZ

GNOME Keyring

NetworkManager

Closing

The grand goal of all this is to