[kdepim-users] I want to stay with KDEPIM-2, Akonadi, Baloo (was: Re: Searching in KMail?)

[Martin Steigerwald]

Am Samstag, 10. Mai 2014, 09:38:08 schrieb Peter Humphrey:
> On Friday 09 May 2014 22:46:42 cgw993 at aol.com wrote:
> > I wish they would just focus on making excellent stand alone applications,
> > that have their own search engines that only work with that application.
> 
> KMail-1 was just like that. Really useful and simple to use, and IMO easily
> the best MUA around. Since then we've had Progress inflicted on us. If I
> thought I could go back to KMail-1 I would (this is a Gentoo box), and to
> blazes with the Brave New World.

I wouldn´t want to go back.

Granted, there are still performance issues with Akonadi… but it is getting 
better and better. And Baloo just performs outstandingly well for me. KMail 1 
was nowhere near that search capability. If I started searched all my folders 
with KMail 1 it was basically unusable during the search which could last for 
half and hour or more since when doing full text search. As KMail 1 read in 
all mail files for *each* search, instead of building an index in the 
background. So instead of gloryfing the old KMail 1 days and basically 
forgetting that searching large maildirs in KMail 1 was a joke, I suggest you 
read on.

With Baloo for me it goes like this:

I type Alt-F2, type "Brave New World" and got your mail, a reply to your mail, 
a mail from BTRFS mailing list and some more results in a fraction of a 
second!

No, I don´t want to go back. This is just too good to miss out again. I want 
to stay with KDEPIM-2, Akonadi and Baloo.

And mail address completion works nicely now as well. *Instantly*.

Baloo is no comparison with Nepomuk. It its faster by factors. 10, 20 or even 
more times faster. *Easily*. I have huge respect for Vishesh for taking this 
bold step to replace something he put a lot of effort in with something that 
just works better, by magnitudes. It required from him to leave behind 
something he put a lot of effort into. Thats a big decision I have a lot of 
respect for.

And added to that: Baloo does part of what you want. It has different backends 
for storing mail and file indexing data. Its not just one big super-index for 
everything. Yes, it is shareable by applications. And I am happy that it is.

The architecture of Akonadi is sound. Using a database as a metadata cache for 
PIM data has been done successfully before with Zimbra, Zarafa and other 
groupware servers. I had a 450000 mail folder with Zimbra. And it *just 
worked*. Including full text search. Zimbra uses MySQL as well. Zimbra powers 
Yahoo mail. It wouldn´t, if it wouldn´t be fast and scalable.

Databases like MySQL and search indexes like Xapian are *made* for workloads 
like this. The old KMail 1 index files just can´t match a database.

Akonadi got good fixes for IMAP last week up to the point it finally seems to 
work okay with a large Exchange IMAP account I use at work – and Exchange´s 
IMAP implementation isn´t very good as to what I heard from Trojita developer 
Jan – Trojita also shows slowness with Exchange, use Dovecot if you want fast 
IMAP. I expect a ton more of fixes for IMAP now that Munich decided for Kolab 
and Kontact as its groupware, as developers get paid to improve it.

And with help of David and Sergio I managed to speed up synchronizing large 
locally stored maildirs considerably, making them usable for me again – it was 
sorting filenames alphabetically needlessly which didn´t work well with more 
than 245000 unread mails in one folder. I will backport this to 4.13.2 if 
there are no problems with it. So there is something in there for POP3 users 
as well[1].

Yet, if you want: You are free to put energy into efforts to keep those older 
versions of KDEPIM alive. I won´t.

I believe in the architecture behind KDEPIM. I see there are lots of things to 
improve upon. I am not yet satisfied with Akonadi´s parallelism as I can still 
make it block out the GUI of KMail while it is stated design goal of Akonadi 
that it separates GUI from background work. But it is getting there and I 
believe it has lots of potential to build upon. Its potential is certainly not 
maxed out yet as recent developments showed.

Was it barely usable or even unusable for quite some users during early stages 
of development? I think yes. Does it even now take painfully long to mature? I 
think yes. Was it frustrating to use for a lot of users? I think yes. But 
thats not due to architecture in my eyes. Its due to the lack of manpower. So 
go help. Or have patience and wait, or stick to something else in the 
meanwhile, looking at KDEPIM from time to time again.

I suggest looking at it with KDE SC 4.13.1 with Baloo. I think its worth it.

This is at least my experience.

Okay, done writing something positive about KDEPIM, Akonadi and Baloo. Took me 
some time, but I thought it was needed.


[1] [Bug 334218] synchronizations of large folders with filesystem contents 
hogs a Sandybridge core for minutes

https://bugs.kde.org/334218

Want to know how long it took me to search this reference again? Alt-F2, enter 
"synchronize mail", done – within fraction of a second again. KMail 1 cannot 
even remotely beat this. It does not even come near to this. notmuch might be 
able to… and you can use it with some MUA, if you want, but I prefer KMail as 
I like its GUI. I have seen no mail client with a GUI I like as much and I 
tried out Icedove and Evolution as I had issues with Akonadi and large IMAP at 
work. KMail just is my favorite. Thus I tried to bear with it as much as 
possible, although I admit it was difficult at times and I was near to jump ship 
sometimes.

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