A little more than a week ago a blog appeared on Qt Labs Blogs. The subject is about The Qt Messaging Framework, in short QMF.  It may look as this is duplicating the work that we have put in Akonadi, but I don’t think that’s quite true. So I hope to explain the differences.

Yesterday I wrote that Akonadi is made up out of two parts. First is the database layer (15K loc) and second are the KDE libraries to communicate with that database / cache (35K loc). The database part differs between QMF and Akonadi. QMF has chosen to use SQLite and Akonadi has chosen MySQL.  Why we did not use SQLite is pointed out in our FAQ:

We tried. Really. It can’t handle the concurrent access very well, in the best case this means very slow operations, but we’ve also seen deadlocks and failing transactions. Once that’s fixed in sqlite, adjusting Akonadi to use it again instead of MySQL is no problem.

Currently there is some work done trying to let Akonadi work with SQLite. The database setup is a isolated layer within Akonadi. So as long as it understands SQL and it has a socket or port to connect to, it can be used in Akonadi. Some PostgreSQL patches has been committed too, these were for queries that had a little different syntax than MySQL. And that’s what is needed to get it to work. Some people trying it out, having knowledge about that particular database solution and being able to adapt Akonadi to it if there is a need to.

But when the Akonadi project started, we have had in mind that it should be able to be used as replacement for the file-based backend KMail uses at this moment. That means high speed and high volume data going in and out of the database on a constant bases.  This is very much another perspective than QMF.  You probably won’t open kde-core-devel archives on your telephone, while you will want to quickly see the new messages on that list. Tobias Koenig described the lists of requirements for each project:

Nokia requirements

• mobile phone centric pim handling (mail, sms, mms etc.)
• small memory footprint -> inprocess communication
• low bandwidth consumption
• low data volume handling (results from the previous points)

KDEPIM requirements

• API to access general PIM data (should be easy to extend)
• memory footprint can be larger
• inter process communication to be more robust
• handling of huge amount of data (as usual for desktop system)

As we have seen from KMail from the past, taking one solution to fit the other will result in nasty design (sorry KMail ;-)). Akonadi will work in the future on the somewhat fatter mobile devices and that’s probably where QMF and Akonadi will meet each other. I don’t see QMF used on desktops and I don’t see Akonadi used on thin mobile devices.

The second part of Akonadi are the awesome libraries which are created to access the database. For an application developer there is no need to learn sql and do tough queries, no the libraries deal with that. These contain of classes with a KJob API to manipulate data on a low level. Somewhat above that there are models , views and proxies to present the data to the user. They are in the library because we want a consistent look between all PIM applications.  The folder view of Mailody will look roughly the same as the one from KMail, at the minimum it will contain the same data. If you mark a message in Mailody as important, it will show up in KMail as important instantly and also in Lionmail (the plasma mail viewer written by Sebas) too.  On an even higher level it provides dialogs. So editing a contact in KAddressBook is exactly 100% the same as editing it in Mailody when you choose that option from the address book in the composer.

A library to this extend is not provided by QMF and there is probably no need for that. Last point I would like to make is that QMF is specialised in Messaging. Akonadi is type independent. It really does not matter if you want to store mails, contacts, appointments in there, you can even store bookmarks,  chat logs or kittens in it.  That last one has not been tried though.