Holy Grail? No thanks, we’ve already got one!

KAddressBook and gtkAddressBook with same data

On the left is KAddressBook from KDE4.4, written in C++ with the KDE/Qt platform retrieving data from Akonadi. On the right is gtkAddressBook written in python with the PyGtk platform retrieving data from Akonadi.

KMail and gtkMailReader

On the left is KMail 4.5 (not ready to be released with KDE4.4), written in C++ with the KDE/Qt platform retrieving data from Akonadi. On the right is gtkMailReader written in python with the PyGtk platform retrieving data from Akonadi.

In both cases, the actual data – the emails and contacts – come from a kolab server, but none of the applications have any code that it aware of what Kolab, IMAP, maildir, POP etc are. Akonadi handles all of that. Both applications of the same type on different platforms show the exact same data and Akonadi keeps it synchronized. If I edit a contact in KAddressBook, the gtkAddressBook is updated automatically and immediately.

The technical details of this will be in a later, longer blog post, but the basic message is that I’ve started working on a proof of concept Akonadi client library written in python using the twisted framework. I’ve also started a more high level proof-of-concept PyGtk Akonadi library, and two concept applications to use it. I could of course have used PyQt or PySide for the Gui, but I wanted to make a point that Akonadi is for GTK too. It is truly cross platform. An Akonadi client library is a library that communicates with the Akonadi server, where all PIM data can be stored. We already have a maturing library written for the KDE platform in kdepimlibs, which KAddressBook, KOrganizer, KMail etc are currently being ported to. There is already a proof of concept Java client library for Akonadi, and now there’s a proof of concept for python too.

What next?

Python already provides useful facilities for PIM data. There are existing classes for handling different types of data, like emails, vCards and iCalendar. This adds possibilities for writing Akonadi resources not just in C++, but also in python. You could write a new Akonadi resource for the next social network everyone must join, and feed its data into Akonadi, and all the applications would not have to be changed, and nothing would need to be recompiled.

Another possibility is using scripting to modify or handle the data in some way by writing Akonadi agents in python.

Also, because the Akonadi server is written in pure Qt (no KDE dependency), and python-Akonadi does not depend on KDE either, this could be used to create a new PIM framework on platforms where python and Qt are available, but KDE is not. Such a framework could be attractive to third party developers to create PIM applications without considering the transport mechanism or details of storage. This would be a bit more work, but given that there are already frameworks like twisted to handle transport and other libraries to handle storage, it would not be excessive.

I know the gtk applications don’t look good or useful. They’re not supposed to. I had never written anything with the Gtk API before yesterday afternoon, so the only purpose is to demonstrate that the data is available and comes from Akonadi. If you want to improve any of this the code is on gitorious here.