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

KAddressBook and gtkAddressBook with same data

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

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.

5 Responses to “Holy Grail? No thanks, we’ve already got one!”

  1. Thomas McGuire (tmcguire) 's status on Friday, 09-Oct-09 16:56:53 UTC - Identi.ca Says:

    […] Holy Grail? No thanks, we’ve already got one! « Steveire’s Blog a few seconds ago from web […]

  2. Andreas K. (hamburger1984) 's status on Friday, 09-Oct-09 21:17:44 UTC - Identi.ca Says:

    […] Holy Grail? No thanks, we’ve already got one! « Steveire’s Blog a few seconds ago from choqoK […]

  3. Cross platform Akonadi video « Steveire’s Blog Says:

    […] This is a follow up to my previous blog about a Gtk Akonadi library. […]

  4. MaurizioPz Says:

    Hi Steve,
    I’ve found today your python-akonadi library. I find it very interesting and useful. I’m thinking of using it to create a plugin for conduit so that it can access akonadi resources. I’ve read that this library is intended as a proof of concept, so I’m writing you because I wanted to know if you are planning to continue maintaining it and if you have any suggestion on how to approach the development of this plugin for conduit.
    Thank you for your time

    Maurizio

  5. Data fragmentation between ‘owning’ services? « Steveire's Blog Says:

    […] because they might think it depends on something fictional like the KDE desktop environment, which is clearly not the case. The point is though that non-adoption of common infrastructures between […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: