After spending some time with Inkscape I came up with a computerized version of our nice Akonadi architecture diagram. Inkscape is a great tool. It crashed once and I wasn't able to figure out how to put text on an arc path in a way that is also readable when the arc is upside down, but other than that I really enjoyed working with it. The concept of immediately applying all changes you do in dialogs to the document is much more intuitive than having a complex "ok, apply, cancel" mechanism. The context-sensitive hints about the meaning of mouse clicks or keyboard shortcuts in the statusbar also are really helpful. They remind me of a similar feature of XFig which still is my favorite vector drawing application. But I guess Inkscape is catching up.

Back to the topic. With Akonadi we aim to create a PIM Storage Service which supercedes the combination of KDE specific technology we use right now as backend for accessing mails, calendars and addressbooks. During the KDE 3 series we gained a lot of experience by connecting the KDE PIM applications to a wide range of groupware servers, like Kolab, Open-Xchange, OpenGroupware.org, eGroupware, GroupWise and more through a variety of different protocols. One of the key conclusions on the technical side is that a model of something like "live access" to the server doesn't turn out to be viable in practice. A caching, offline-capable model is much more appropriate to solve the problem at hand. Another conclusion, this one more on the social or process side of things, is that trying to do all this only for one specific application is a waste of resources. Cross-project collaboration is the key to success.

All this considerations and much more (some of them you can read in the documentation of the Osnabrück 4 meeting) lead to the Akonadi architecture. It feels right and I'm pretty confident that it has the potential to not only become the base for the PIM applications of KDE 4, but also be useful to serve as base of the free desktop in general. We, as KDE PIM team, are dedicated to make this happen.

In connection with Akonadi I also started a discussion about the KDE PIM 4 roadmap on the kde-pim mailing list today. It's an interesting question when we will be able to release something under the KDE 4 label. My personal opinion is that we should take our time to complete something which really is relevant. There are so many ideas and emerging and on-going projects which have the potential of becoming killer features of KDE 4 that it would be a pity to bury them under a release schedule which focuses on releasing something as early as possible.

With KDE 3.5 we have a rock-solid stable platform which is able to serve the needs of users as well as developers for some more time (I would even say years). Combine this with the rocking applications which are not part of the KDE core releases like amaroK or the upcoming OpenSync and its KDE frontend and you get an incredibly promising perspective for the road to KDE 4 and beyond. This will be a fun ride!