[Kde-pim] Akonadi as metadata caching middleware

[Martin Steigerwald]

Am Donnerstag, 12. April 2012 schrieb Lindsay Mathieson:
> On Thu, 12 Apr 2012 01:15:28 PM Martin Steigerwald wrote:
> > The approach Akonadi takes is in use by quite some groupware
> > solutions already. At work we have Zimbra. And guess what, they use
> > MySQL to hold metadata for mail. And they use Lucene to index them.
> 
> yeah, but Zimbra also *is* the Mail Store and the client - very tight
> integration. Akonadi is attempting to sync with the mail store. Clients
> talk to Akonadi.

Ok, they might be tighter integrated. But what gives? The web client is 
still on my client machine and the server component still on the server - 
so they need to speak some kind of protocol with one another. You can have 
a caching server-like component on your desktop with Zimbra Desktop and I 
think then thats quite similar to Akonadi.

I really do like that applications speak a clean AFAIR IMAP based protocol 
with the Akonadi server. And that - like in Zimbra, also the Zimbra 
Desktop client - the heavy work is done in the background.

> > I type in some search keywords and get results from full text
> > indexing that takes place in the background in about 10-15 seconds
> > at maximum, often quicker. Full text and way more than these >320000
> > mails in about easily 100 folders.
> 
> Yeah, I do that with Thunderbird too - 30,000 plus emails, in imap
> folders.

30000 mails are no big issue with KMail from KDEPIM 4.4.5 here either. I 
talked about 10 times as much. Just in that one folder.

But still KMail gets jerky then. While building up the folder contents of 
kernel-ml with 41407 unread mails at the moment. And it takes easily a 
minute to display / build up the folder completely with threading. That on 
a Intel i5 Dualcore Sandybridge machine with Intel SSD 320 - a blazingly 
fast laptop.

KMail 1 already displays incrementally - since the rewrite of the mail 
list view in KMail 1. But it insist of still displaying all mails in the 
folder. While the Zimbra Web client just displays the first 1000 and then 
waits what the user wants to do while being reading to update quickly if 
needed.

So what I like to see from KMail 2 / Akonadi is that all the heavy work is 
done threaded in the background and the GUI is always fluid. And I think 
implementation wise thats already the case, maybe except for some GUI list 
build up stuff, but I believe even there, its mostly Akonadi doing the 
work. Maybe it needs some improvements, but I really do think that KDEPIM 
2 can get there. The technology used should be able to enable that.

With KMail 1 this IMHO would have been impossible without a complete 
rewrite.

Can you say that from Thunderbird? Is it fluid at all times? It may be that 
they are using a similar approach to searching and use background 
indexing.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/