Tuesday we lost Ramses Shaffy. A popular, charismatic dutch singer. He was popular when my parents were younger, so I was confronted with his songs while i grew up.

The lyrics were fascinating and mostly cryptic. for those that want a taste of dutch culture, here is a nice song, the title catches aspects of life and translates to: sing, fight, cry, pray, laugh, work and admire. The clip shows appropriate stills at each word.

That’s my result of a weekend hacking in Essen. You probably don’t understand it. So I’ll add some explanation. You are looking at akonadiconsole, the debugging application of Akonadi. I’ve extended an existing resource where you can configure the filesystem path of your images. It will list all subdirectories and when clicked on a folder, it will list all images. When you click on an image, it will fetch the thumbnail of the image and show it.

That covers the most basic functionality that is needed for Digikam as far as I can tell. Of course a lot of work has to be done in Digikam to ever support Akonadi resources.

It’s just a start of a resource which shows how the Digikam and KIPI-plugin people can integrate Akonadi in their application. I know Colin Guthrie (the original author of the resource) and Luka Renko are interested in working on this more. I hope this will give them a head start, and I’m happy to assist where possible and add some code here and there.

While the planet is flooded with reports from the marketing, promo and www sprint, there is another sprint happening in a beautiful place called Essen in Germany.

I arrived there in the afternoon. It was nice to finally meet the people behind Digikam and the kipi-plugins. A few years ago I learned C++/Qt hacking while working on Digikam. It was a wonderful time. Since then I’ve moved on, but I’ve returned to this sprint to give a presentation about Akonadi. As Akonadi is fully type independent, it is able to be used for Digikam. It would open a nice new set of oppertunities.

For example, you could organize your images while your offline. Not only the images on your local hard disk, but also on your Facebook, Flickr or Gallery based website. As soon as you connect to the internet again, it would execute all the moves. Can make that train trip to Berlin so much more productive, right?

Another feature would be to use your image based resources to attach an image as an attachment to an email. No longer select an image from disk, but select an image from an album, as you would see them in Digikam.

I’ve not realized that at a Digikam meeting there would be a lot of people with digital camera’s around. We already decided that it looks a lot more like Digikam Next Top Model, instead of a Digikam sprint….

Day 2 ended with some hacking and adapting stuff to the API changes we did. I worked on Mailody and implemented support for contact groups. That are groups of contacts, also called distribution lists. In the address book within the composer you can now see them and when you click on it, the individual members of that group get added to the recipients list. I never had group support within Mailody and adding it while using Akonadi was not more than like 40 lines of code.

After that I worked to get the manual expunge code, which I explained on Friday. The DBus interfaces were added by Kevin and I adapted Mailody to use them. So that was one of the last goals I had for the meeting. In the meanwhile Thomas McGuire yelled that his rewrite of the pop3-resource was pretty much complete and passed his unit tests.

Day 3 was somehow a bit more relaxed than the other days. We briefly looked over the last bit of API we had to review. It was coming from the KMime library. KMime is a library that has been around for ages and was written with the intend to replace mimelib which is used by KMail. But that never happened.

KMime is the library that is responsible for creating the actual message after you press the send button in an email composer, but also deals with extracting the different parts from a message to display them, extracting the plain part, the HTML part, maybe some attachments, but also dealing with all kinds of encoding and decoding problems which are used to send the actual mail in.

When I started Mailody, I first tried to do that all on my own, but I soon realized that was not something I wanted to do, and Volker pointed me to the – at that moment unused – KMime library. After we removed the dust, we discovered some bad API and for KDE4, we removed most of the ugly API (like methods returning QList* (yes returning pointers to a list with pointers). Mailody then turned into a happy user with KMime. With the akonadification of KMail, it is needed that KMail also used KMime internally. Akonadi delivers the messages in that form to KMail, so it needs to. Andras Mantia has been actively working on this conversion for KMail. I’ve big respect for that work. I know it is a big task and probably not the most fun to do.

That also mean there is a new user of that stuff, and that means some API changes are wanted. We are still not completely happy with existing API, so that makes the extensions to that API somewhat less critical to get absolutely perfect. This is one of the candidates for a rewrite for KDE5. Still reading? Sorry to be a bit verbose on this stuff, just want to make sure you get a feeling why an akonadified KMail is not available yet. From one big monolithic application, it is being teared down to separate components, which will make the codebase a lot easier.

You have to have bad api’s to realize the value of good API’s.

After this mandatory part of the meeting, we quickly went over to the other mandatory part and did the Group Photo. I’ve not seen it yet, but I’m sure it will appear on the Dot or Planet soonish. There were a couple of discussions between various people. It’s fun to see that the base of Akonadi works nicely for a lot of people and we are slowly arriving at the phase were we can extend it further. Hot Topics in that area are:

• Search. You can basically split up two types of searches. The first one is in the messages within Akonadi. We will use Nepomuk for that. Especially now Virtuoso back-end for Nepomuk seems to be performing nicely, we can go ahead and implement them further. The ground work is already present; Akonadi supports creating virtual search folders, containing links to messages in other folders. Also each message passed into Akonadi is being indexed by Nepomuk. Just need to finish up that work as far as I know, like creating a user interface for creating such a search folder. The second type of searches are server side searches. Take IMAP. It allows you to search for messages directly on the server. We need to support that too.
• Filtering. Basically you have the same difference. There is a local filtering of messages, which is implemented by a summer of code student. It means that a special type of resource gets the messages before it gets added to the final destination folder. That special resource can filter it to another folder for example. This should all be finished, but it’s not completely ready yet. There is also filtering on the server side. For example IMAP filtering is (and should) be done on the server side, for example with Sieve. Volker and I briefly brainstormed about the possibility to create an application which can deal with that. Should not be too much work if we can base it on the work already done by the SOC student.

I briefly brought up Google Wave. I think Akonadi can easily provide a resource for it, although there wasn’t much interest from the participants of the meeting to work on it, so we probably will not work on it ourselves. Of course if the resource is created, you’d still need an application to edit the waves. So if anyone wants Google Wave integration into KDE, please use Akonadi as base. We can help you with the stuff, we just don’t have time to do it ourselves.

That pretty much concludes my coverage from the meeting. I know there will be a dot story outlining more stuff that has been done during the meeting, outside the little box I have lived in. It was fun to be there again.

We decided that there is no real use case to keep the akonadi kcm within the systemsettings. The settings in there control which database server should be used. So it has the potential to break a lot of stuff. If you change databases, there is no migration tool, so you instantly loose all your settings, which in the user case will lead to the disappearance of their contacts. The config kcm is now accessible via the Akonadiconsole which is the right place, as sysadmin which want to change the database system, probably know about this tool.

After that we started with API-Review of the Mailtransport classes. Around 1920 everyone used to use their local sendmail application to deliver mail. That was ordered to deliver the mail as soon as the 14k4 modem has made a connection to the internet. A bit later people started to depend on the SMTP method to send mail. The application send the email to the provider which provides your internet connection and then it’s done. But now we are starting to support Microsoft Exchange Servers, we need a new way of sending mail. The feature Microsoft Exchange offers is that it also deals not only with incoming mail but also with outgoing mail. That means we needed to adapt our Mailtransport library to know which Akonadi Resources are capable of sending email.

When you compose a mail you have a selection bar, where you can indicate which provider/transport should be used for sending. That now has been extended to also show the resources that are capable of sending it. And that required a lot of changes. We combined it with nice features as sending messages after a specific date and time and moving messages after they have been send to a certain folder. To our surprise the whole morning was filled with reviewing the API and we have a pretty long list of stuff that has to change there.

After lunch we continued with the API review of IdentityManager. In this KDE cycle support has been added for images within signatures. Signatures in the context of mail messages which can hold company disclaimers for example. A much requested feature was that people (or company policy) needed to insert there company logo in the signature. A couple of KDE releases ago we added support for html based signatures and now we added the support for images. And those images need to be stored somewhere. But in a application independent way. The identities you setup are shared between KMail and Mailody and we need to prevent that breaks with the set image in the signature when you switch between those clients.

Continuing with yet more API review (really a weekend is to short for this). We continued with the API review of the widgets and classes provided by the new address book application. The classes are all in a library so other application can make use of them. One of the discussion points was about the dialog. When you for example click on a phone number and you have a voip phone, it can actually dial that phone number, the same goes for an email address. When you click it the default mail client is opened and the composer is launched. But if you show the dialog in an open composer, you want to add that address to the addressee list of that composer. Implementing that without making the API ugly needed some thinking.

In the evening Brad showed us the progress on Exchange support. He demonstrated Akonadi fetching mails, addresses and appointments from the Exchange server. Although it is in pre-alpha stage, it already shows that the resource is on the right track. From his side, there are pending requests for free-busy listing support and support for filtering. Both will be implemented sooner or later. His biggest problem, the mail sending part, is solved recently.