We are at the Akonadi meeting at the KDAB offices in Berlin right now, which was quite nice so far. We had the first round of API review of new methods in KDEPIMLIBS for 4.5, and already cleaned up quite a bit. Having multiple eyes look at the API is a nice way to improve the overall quality of the API. We met with Andrey Moiseenko and Alvaro Manera of Nokia, who work on calendaring for the next Meego phone from Nokia. They use our KCal library, which they have forked/extended for some special requirements they have. We’re now making plans with them to integrate their changes back to our version of KCal, so that both sides will profit from changes and have a single point of maintenance.
Many of you are interested in the state of KMail 2, which is the port of KMail to the Akonadi PIM framework. We haven’t communicated much about that lately, as most of us aren’t keen bloggers¹. Finally, here is an update for you now. Yesterday, we had an intensive discussion about the state of KMail 2 and our release plans for it. While we made some good progress on it in the last few weeks, we came to the conclusion that KMail is not yet in a state that is suitable for a beta release. With the KDE SC 4.5 beta 1 release approaching fast, we had to go for some plan B. KDEPIM will not be included in KDE SC 4.5 beta 1. Instead, we will concentrate on making KMail more stable and usable, and release the first beta version of KDEPIM one month later, at the time when KDE SC 4.5 RC1 will get released. That gives us some time to finish important bits and bring KMail 2 to a state in which it can be used.
This means that there will be no fresh KDEPIM packages in KDE SC 4.5.0, and distributions should ship the KDE 4.4.x version of KDEPIM instead. The final KDEPIM release will then follow a bit after the SC 4.5.0 release, at the same time as KDE SC 4.5.1.
KDEPIMLIBS is not affected, it will be released together with KDE SC 4.5.0 as planned. The rest of KDEPIM progressed very nicely: Tobias fixed a lot of problems in KAddressbook and brought back some missed features. The Akonadi port of KOrganizer is also working quite well. However, releasing KDEPIM without KMail is not an option, as it is a quite important part of the PIM suite. We briefly pondered replacing KMail with an older version for the release, but that would involve ripping apart and moving around the dependencies, which is a lot of work and has a high risk of regressions. I think delaying the release is the best option here, as it gives us some more time for stabilizing without too many downsides.
If you’re a KDE developer, please try out the beta version of KDEPIM when it gets released and help us making it work for your usecases. I hope the revised release schedule will work out, keep your fingers crossed :)
So basically the release of KDEPIM will happen a bit after the KDE SC 4.5.0 release. We’re not sure about the release name yet, maybe we should call it “Preview” or something like that, just to prevent the endless discussion and flames about naming that happened with the KDE SC 4.0 release.
KMail 2 is a major rewrite of KMail: We throw out the ancient brittle storage layer and replaced it with Akonadi. On top of that, we ported it from the mimelib library to KMime. Finally, we factored out much of KMail into separate libraries, such as Akonadi itself, the messageviewer component, the messagecomposer library and more. That allows us to re-use those components in other applications, such as the mobile version of Kontact, and makes it possible to unit-test the components, which was not possible before, as everything was tightly glued together in KMail.
Such a major rewrite is not without consequences: On the one hand, it will finally modernize the complete architecture and make it maintainable. On the other hand, such rewrites always introduce regressions and remove features. This is unavoidable, and it is always a compromise between releasing and between stabilizing. Software would never get released if the requirement would be to make it regression-free and feature-complete.
What does that mean for KMail 2? With the first release, some features will be missing:
- There will be no on-server filtering for POP3. I guess most people weren’t using this anyway, as it was actually quite hard to configure this correctly in KMail 1. Normal client-side filtering will still work, which is what everyone uses.
- There will be no attachment loading on demand for IMAP. In KMail 1, with online IMAP, it was possible to activate loading attachments on demand, which means attachment will not be downloaded when viewing a message, but only when the attachment is actually saved to disk. This had some problems in KMail 1, like attachments having a size of 0 bytes, but it also sometimes worked. While the Akonadi architecture supports retrieving only parts of items, we don’t use that yet in the message viewer.
- The most hated KDE bug will not get fixed. The bug is that KMail’s UI will freeze when the incoming mails are filtered, which is especially annoying for slow filters, like the filters that pipe the mail through spamassassin. That is not a regression from KMail 1, but we had hoped that the bug would be fixed with Akonadi. The idea is to use a filtering system which runs in a separate process in the background, instead of doing the filtering inside of KMail. Such a filtering system was created in a summer of code project last year, but due to lack of time, it is not yet integrated in KDEPIM. That means filtering will still be done on the client-side in KMail, with the consequence of freezing UI. Once we get a release out of the door and have some time, we will integrate the new filtering framework that will finally solve this bug.
- We’re not sure if we manage to be able to migrate the IMAP cache if you’re using disconnected IMAP. That would mean re-downloading the mail again.
- Probably IMAP server-side searching will not make it either
As said earlier, KMail is not yet ready for being released as a beta version. One major blockers right now is the lack of data migration, which includes reading the old KMail 1 index files and storing those flags in Akonadi, and also migrating over the account configuration. This is being worked on at the moment by Kevin Krammer, so we’ll have data migration before the first KDEPIM beta. The other blocker is the lack of client-side filtering, which Volker Krause is working on. As said above, that will at first be almost the same filtering system as we had in KMail 1, which allows us to have a working client-side filtering system for the first KMail 2 release. After those two blockers are fixed, which is before the first KDEPIM beta release, KMail 2 should be usable for other developers and testers, and we can concentrate on making KMail 2 usable for daily usage.
So the major changes in KMail 2 happen in the background, mainly not visible to the user, as the user interface largely stays the same. We have talked about the advantages of the Akonadi framework in other places, so I won’t repeat that here in detail. Overall, the porting to Akonadi is an important step in long-term stability and maintainability, and also fixes the old architectural issues we had with our 10-year-old system. I’m looking forward to the release of KMail 2 and of the ported version of KOrganizer and Kontact, which finally gives as a new architecture that meets modern requirements.
¹: No wonder I’m not blogging much, writing this blog took a long time :)