Akonadi hackathon in Aachen

Since the Osnabrueck IV meeting where we came up with the core of the Akonadi concept and design, the implementation and fleshing out of these concepts hadn't progressed quite as quickly as we would have hoped. We're all madly busy with real-world concerns and other KDE stuff, so that wasn't really surprising. To finally lift it off the ground and get it to a stage where hopefully more people can start to see the potential and contribute, we decided a few days of meeting face-to-face and hacking around the clock would be best. To keep it effective, we only wanted a small group of people who know the PIM stuff (old and new) intimately. Initially Nuernberg, Germany was to be the location, what with SuSE/Novell, Cornelius and Will there, but that didn't work out for logistical reasons. Ingo, who has recently moved into a larger apartment, then volunteered to host the meeting in Aachen. Cornelius and Will couldn't make it, in the end, so it ended up being Ingo, Volker (who lives in Aachen as well), Tobias and myself. Details and pictures after the jump.

The meeting, which took place last week, was as productive as expected, it's amazing how much momentum 4 KDE hackers locked in a room for a couple of days can develop. We managed to flesh out my initial server implementation to where it can list collections (folders and virtual folders), list items in these collections (mails), upload items into the store, set flags, and a few more things. The client library that provides the KDE version of the API that applications will end up using, talks to the server and puts it in a set of Interview models, which various demo views use. These will be the building blocks of what used to be KMail, Kaddressbook, etc, usable by everything on the desktop that needs to display collections of PIM items, or individual items. The king is dead, long live the king.

Since the client/server protocol used for the bulk transfers is IMAP (with extensions), trusty KMail 1.9 can use the Akonadi server like a regular old IMAP server. That means that we'll have a fallback at least for mail, should the new front ends not be ready for 4.0, and it means that you will also be able to get to your mail using mutt, even if it comes into Akonadi from an Exchange server. Or Evolution, for that matter, although we are hoping that the Evo guys will one day use the glib client library to integrate it more tightly. All the non-data communication for things like notifications or triggers is done using dbus, which among many other benefits means that, even if the other PIM players on the desktop (Evolution, Thunderbird, Sylpheed, etc) decide not to support Akonadi natively, we can still agree on dbus interfaces for things like new mail notification for better interoperability.

So now we've got the datastore (a bit of a misnomer, since it is a cache and metadata store, the actual data can still come from servers or non-db on disk storages) dishing out and taking in stuff, it's time to write the resources, which fetch stuff from various sources and make them accessible to Akonadi. These are standalone processes that use the library to talk to the server, and provide a dbus interface, which is still being designed. That should make things robust and allow the resources to be tested and used standalone. If that reminds you of KIO-slaves, that's no accident. Volker has started on the notification manager and interfaces, and Tobias will tackle the last missing piece, the domain-specific search and query handlers). Since we don't want the server to have to know about parsing, say, calendar items, there is a separate process for each kind of data that does the parsing, indexing, metadata mining, etc, and feeds it back into the server.

So lots to do still, but hopefully we can attract some new contributors with all this. The days when hacking KMail and KDEPIM was only for masochists and people who like scary code are over, ladies and gentlemen. The server uses only Qt and DBUS, no knowledge of KDE libraries is needed to hack on it. There are lots of small self-contained jobs that should be perfect for getting your hands dirty, such as writing unit tests for an individual command handler, or implementing one of the missing handlers. Writing resources should also be nicely self-contained and not require much knowledge of outside stuff. The code is all new and shiny, it has unit tests, comments, and you can still read it all in an afternoon. An ideal time to come in and help shape the future of how people do mail, calendaring, contact handling, feed reading etc on the free desktop. All of the view layer stuff, the graphical interfaces, can be rethought as well, and make use of all the cool stuff that is in Qt4 and kdelibs4. We already have two Google Summer of Code projects exploring new ways to represent PIM data. So come on, you fancy interface people, show us how to make an addressbook sexy. ;) We'll also need someone with glib knowledge to step up and write the non-kde version of the client library, which can then be used as the basis for bindings to Ruby and friends.

Although they were not at this meeting, I'd like to publically acknowledge the work of Andreas Gungl, who is working on the database backend schemas, and the server robustness and overall design input of Martin Konold, of Kolab server design fame. Everyone else who contributed to the Akonadi birthing (and name finding) session in Osnabrueck deserves credit as well, of course, as do all those who've given their input in discussions in person and via email. It's coming together at last, boys. :)

And finally, here are some pictures from the meeting.