Status of automated KMail migration

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.


Akonadi Sprint, Final Day

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.


Osnabrück PIM Meeting 2010

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.


Akonadi-like access to data in files

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.


Akonadi migration explained

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.


Akonadi porting explained

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.


100% mimelib free

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.


O Brother, Where Art Thou?

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.


Akonadi Resources for Google Contacts and Calendar

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.