Those who have read my previous blog entry will remember that I have been working on a way to directly operate on a mixed tree storage layout.

"Mixed tree" means that the mail folder tree (hence "tree") consists of Maildir and MBox folders nested in each other in any combination, e.g. Maildir inside Maildir, MBox inside Maildir, Maildir inside MBox.

Since this is highly KMail specific, it should probably be called "KMail tree" or "KMail mail directory", but there is always room for improvement, especially with naming.

As you most likely have already read on various other blogs we had one of our Akonadi sprints for the past couple of days.

Today was my last day at AviBit Gmbh where I have been working for almost nine years now.
Starting with development of internal tools, becoming maintainer of some of the companies main components and finally designing and supervising implementation of a versatile client framework for our surveillance products.
What a ride :)

Nine years of Qt development for multiple platforms (mainly Linux though), on a KDE powered desktop using my personal favorite editor Kate.

It's that the year again when KDE PIM developers attend the annual meeting in Osnabrück, traditionally hosted by Intevation, one of the companies which continously excels in acquiring funding for KDE related development.

Tom already blogged about it and there will be a Dot article as usual.

Some of Akonadi's resource agents (usually just called resources) work on local files, some on files containing more than one data object, some on directories containing one data object per file.

For example the "VCard Resource" has one vcf file to work with which in turn contains any number of vcards, i.e. contacts.

Those single file storage containers have a couple of things in common so of course we want to share as much of code between their respective resources as possible.

In an attempt to follow up on my blog about Akonadi porting xplained I am going to write about Akonadi migration.

It is basically the data storage related cousin of porting:
Porting is, as we learned, about adapting applications to a new way of handling data.
Migration is about adapting data to new ways of being accessed.

The last couple of months I unfortunately had too little time for development on either KDE or Akonadi so I spent the available time on thinking about mail migration.

For quite some time almost every blog by a KDE PIM developer is about Akonadi in one for or the other, often about "Akonadi porting" or "porting to Akonadi".

Akonadi itself can already be difficult to explain, combined with "porting" it probably has only meaning left if you are a developer.

If you have no idea what this means, don't worry, neither do I.

What I do know, however, is that a lot of people around KMail and are extremely happy about this :)

Basically the folks working hard on porting KDE PIM apps to Akonadi have reached one of their bonus mission goals: they've got rid of a very old, very obscure, tedious to maintain, mindboggling to work with (you get the picture, right?) legacy part of the mail handling framework.

Not at the Akonadi sprint. Shame!
(You can find Tom's blog about it here and here)

Missing out on the API discussions would have been already bad enough, missing the presentation of my GSoC student and not getting to meet Brad Hards sucks.

Anyway. Despite not having fun^Wto do a lot of work in Berlin, I still have something Akonadi related to blog about.

There has been some confusion about Google data capabilities around the KDE 4.3 release.

The 4.3 Feature Plan has an entry for that and it is marked as "Completed".

What it meant is that the Google Data resoures by Adenilson Cavalcanti would be available at the time of the 4.3 release, however it got, understandably, interpreted as being part of KDE PIM in 4.3.

Lesson learned: don't put features which are not part of the main modules on the feature plan.