KMail as components, Akonadi Mail Reader
ervin | August 20, 2009 | 16:50In my previous post, I’ve been discussing our progresses on some protocols support, and that Akonadi could now be fed with quite some mails. That’s neat to us developers who can make application harvesting data in there… But for the user it’s not really useful if he can’t see the data.
Well, recently I’ve also been working on showing up collection statistics we can get from Akonadi, and also I ported KMail message list view to Akonadi (also making it a separate library). In the meantime, the fearless Andras has been porting KMail mail reader view to Akonadi (also making it a separate library).
In fact, it is the current thread in the huge task which is the porting of KMail to Akonadi. We’re ripping KMail apart, each important set of features are factored out in a library and ported to Akonadi. In the end we’ll have a KMail completely based on Akonadi. But also, it will be much more modular, reusable for other mail clients, but also news readers, etc. Which means that the new architecture will be better suited at supporting a wide range of devices and a good base for future works.
Anyway, both Andras and me had a small test application for each of our new frameworks… So I took some time to merge the features of both into a single application: the Akonadi Mail Reader. This new baby is mainly a prototype to toy with ideas and try out the components we’re making out of the monolithic KMail. Still, it weights just under 400 lines of C++ code, and you can completely browse all the mailboxes you configured in Akonadi thanks to it. Of course, here is the obligatory screenshot:
It looks so much like a miniature version of KMail that it is almost scary. But don’t fool yourself, there’s a lot to do to have a full fledged KMail which will be only based on Akonadi. We’re not there yet, still it is nice to see the whole thing taking shape, in particular to reach the point where you can actually read your mail over IMAP using this small prototype and feel almost at home with it thanks to this familiar touch. 
From my point of view, the KDE culture of working a lot with components really pays off. KMail was first created at a time where this KDE culture didn’t reach it’s full potential yet, hence why we need to refactor it now. But, following this culture it is really nice to see that we’ll end up with small packages of mail client functionalities, and, that thanks to them and to Akonadi, it will be easy to integrate them in any application. We made a relatively complete mail reader in under 400 lines of code, so simply displaying mail content in your application or a message list becomes a trivial task.
Do you think that we’re going to have KMail completely based on Akonadi and stripped from KDE3/Qt3 support by 4.4?
Btw. thanks a lot for you hard work on making KMail rock.
I’m not the KMail maintainer and ultimately it is his decision. His current plan is to have an Akonadi based KMail officially in KDE for 4.5. We might have something working by 4.4, but I think he is definitely right to give it more time to mature before our user base at large switch to it.
If you can write apps that string together components a a few hundred lines of C++, you could also write the app in a few hundred lines of Python or Ruby. So the component approach also works very well for scripting languages and RAD.
Guys, this is great work. I have two questions and a request to make though:
1) What is the state of the porting of the other pim applications?
2) What is the state of the imap akonadi resource? I tried to use the one shiped with 4.3 but it is not reliable and only gets mails from the inbox (all other folders are empty). I know I should file a report about this but the server is not one I could create an account for testing.
As for the request. Could you please, please, PLEASE give a bit of love to the kmail message tooltip? It looks right out of CDE, not KDE
This is awesome, the port of Kontact to Akonadi is one of the things I’m really waiting for. Once it is done, there will be endless possibilities for the PIM inside KDE, thanks for your work.
What will happen to the classical kmail. I simply refuse to run akonadi as it takes way too much system resources for which I paid a lot of money – to be able to edit my images, not run a mail client. If you are requiring akonadi then I’ll rather abandon KDE as a desktop environment now…
A dozen monkeys with typewriters would probably come up with a working KDE application. I mean, 400 lines of code for this thing, wow!
@Luis:
1) AFAIK KAddressBook is pretty much done, and KOrganizer is worked on as I’m typing. But obviously my overview is not as good as KMail as I’m almost exclusively focusing on this one right now.
2) The one in 4.3 is a bit lacking compared to what we have in trunk right now. As I said earlier it’s not to be used in production, it’s really just to give you a taste of it. For the one in trunk we fix issues as we find them, but it seems reliable right now (at least on the servers I test with).
And for the tooltip, weeell I’m not exactly gifted to make it pretty, you’ll have to find someone willing to make a mockup and we’ll see what could be implemented.
@Karl
Well, as I said I’m not KMail’s maintainer so I could be wrong. But AFAIK there’s no plan to keep a “non-Akonadi KMail” once the Akonadi port of KMail is considered stable.
As for your refusal to run Akonadi, well I’m not the one to tell you what to run or not, but honestly it’s very likely that the Akonadi port of KMail will actually be lighter overall than the old one IMO (for an equivalent feature set, since the Akonadi one will, optionally, be able to do much more). Talking about the bit I know best, the IMAP support alone is faster (and I mean *way* faster) and more efficient than the one of the old KMail…
I shared my worries about Akonadi’s performance with Karl, so I’m delighted to read that it will probably perform better. However, I wonder how that is possible? AFAIK Akonadi uses a MySQL database, and KMail does not at this moment. Could you please explain in more detail how it’s possible that Akonadi could possibly perform better and consume less resources than KMail regardless of it’s requirement of a database?
@ervin,
thanks for your take on the plans. So I will switch, as I have no need nor the wish to run such a processing and heavy application as akonadi – which would effectively lock my data into a database format with which no other application would be able to work with!
For example I have no need for IMAP support at all (I simply don’t leave email on a centralized server) nor any of the other heavy weight features!
My desktop applications must be able support my main tasks without taking too much resources from the machine – and akonadi with its database requirement takes way too much resources to be considered worth the effort! Btw. Nepomuk is excluded here as well, same reason – unfortunately another database lock down of data which must be shareable with windows and especially non-KDE applications!
To give you a perspective: When using akonadi and nepomuk on my machine half of it’s 4Gb of memory are taken up by the desktop environment – which immediately results in paging requests as soon as I start working with the large images and virtual machines I need to get my main tasks (editing raw DSLR images) finished.
@Alexander
Well, that mainly comes from the fact that KMail to cover search and archiving needs of your mails had to do the indexing and retrieval all by itself. We effectively had a kind of KMail ad hoc database system built in… so at one point you have to realize that people who actually work on database servers are better than you at this game. So instead of an ad hoc, inefficient, resource consuming KMail database, we’re using a real database system which performs much better and uses less memory for retrievals (for instance).
@Karl
Regarding memory consumption, I’m really surprised by your claims as I’m definitely not experiencing the same thing here. I can’t tell for nepomuk, but for akonadi the consumption would be more around the hundred of megabytes for me (and keep in mind I’m talking about a debugfull build with quite a lot of different services loaded in there, a release build with only POP3 for instance would consume much less). I think you should probably revise the way you’re making memory measurements, it’s definitely not a trivial task and one can be easily misled there. Lubos Lunak has very good posts on the topic.
Regarding the data locking, that’s completely wrong. It is not the case, if you download your mail via POP3 for instance, all your mail will be stored on disk in maildir format as usual, and it’ll get indexed. You should really see Akonadi as a cache for the data for us to make more efficient operations, not as the primary data store (which still is your filesystem, or your IMAP server, etc.).
If you want more information on the topic, there’s a very good Akonadi FAQ (the second point is particularly relevant to this discussion):
http://techbase.kde.org/Projects/PIM/Akonadi#Akonadi_FAQ
@Karl: Why do you think that Akonadi creates a vendor lock-in for you? I think I heared of someone working on Akonadi integration for Evolution. Once Akonadi gains some traction and becomes widely used in KDE, I’m quite sure that more mail programs will adopt Akonadi in some way.
“Could you please explain in more detail how it’s possible that Akonadi could possibly perform better and consume less resources than KMail regardless of it’s requirement of a database?”
I’d turn this on its head and ask “why wouldn’t it?” – databases pretty much exist in order to provide fast read/ write access to large volumes of data without having to cache all (or even a fraction) of that data in memory. Where does this stigma about database resource consumption come from?
@ervin
“And for the tooltip, weeell I’m not exactly gifted to make it pretty, you’ll have to find someone willing to make a mockup and we’ll see what could be implemented.”
Dolphin has a beautiful tooltip which I think can be used.
One more thing, is it possible to make all Qt tooltips look the same (like the one in dolphin), maybe from the Oxygen style?
@anon
In my case it was just other people voicing concerns about Akonadi’s resource consumption, which made me worried as well. Those others are not just Karl here, but for example here – http://randomtechoutburst.blogspot.com/2009/07/kde-43-more-ranting-review-comment.html – as well. But thanks to ervin’s explanation I’m convinced now that there is no need to worry.
[...] and modify it. That is a design feature which makes it possible to access your emails in Mailody, KMail and plasma, and have it all in sync. Always. By using Akonadi, KJots notes can be synced between [...]