Goodbye for now, kmail

Martin Steigerwald martin at lichtvoll.de
Fri May 5 23:05:56 BST 2017


Martin Steigerwald - 05.05.17, 16:45:
> - Akonadi has no notion of multitasking and background tasks – a folder 
> synchronisation blocks interactive user requests by kmail.

Let me clarify that: At least within *one* resource, which is what matters 
here. During folder synchronisation within one Maildir or IMAP resource 
Akonadi does not respond to interactive user requests issued by KMail. KMail 
then displays the much disliked "Retrieving…" message, but it can´t really do 
anything else, cause Akonadi just does not respond to the request by KMail in 
a timely manner.

From a user perspective this kind of behavior is not acceptable. When I click 
a mail in the mail client, they mail client just has to do one thing it has 
has to do it pretty fast: Display that mail. *Now*. Any second the user has to 
wait for that simple action to be fulfilled directly contributes to his or her 
dissatisfaction.

I didn´t try Claws Mail yet, but I expect it to get this right and this is a 
major advantage of any mail client that gets this right.

Despite all what I wrote, I am still with KMail, cause up so far I found 
nothing as good as KMail regarding usability and set of features. KMail is 
just my mail client, and I want to continue to use it. Due to fast hardware 
and aggressive MySQL tuning I have response times from instant to maximum of a 
few seconds usually. On synchronizations of very large folders this can be 
exceeded already. And sometimes I still loose my patience and do the usual:

- akonadictl stop
- check whether mysqld is still running
- if yet, then send SIGTERM to the process till it really is gone (I know it 
does help to send SIGTERM mutiple times, but I tend to get emotional at that 
time)
- tell KMail to start Akonadi again

This usually helps to be back to immediate responses again, as Akonadi then 
has stopped whatever it started working on, whatever it deems to be more 
important than to respond to my interactive requests.

But the truth is:

If the user has a request, i.e. clicks something in KMail, then there is 
nothing else that can be more important than that. The user is king or queen 
and nothing else matters if she or he has a request to fulfill. As long as 
Akonadi doesn´t get this right, it will continue to the dissatisfaction that 
make people leave.

Akonadi really needs to get this right. Any design that doesn´t take this into 
account in my eyes is fundamentally broken. I think also for Munich it is 
absolutely essential to get this right.


Aside from that Akonadi has to work stable of course – I am indeed surprised 
to read from quite some users that it still doesn´t work for them aside from 
the very annoyed performance related issues I described. For me it is quite 
stable meanwhile. I am still on KDEPIM and Akonadi 16.04. I read reports there 
has been new regressions, but my hope is that developers improved it instead.

I have quite some hopes as I saw quite some people being very active with bug 
triaging. I didn´t see that much of bug triaging activity since quite a long 
time. But what is also required is to fix bugs that others and I reported and 
that are confirmed since years. Its a bit of a challenge to dig out these bugs, 
as there is a ton of duplicates and a ton of quite useless due to lacking 
detail or even insulting bug reports that do not help a bit to improve the 
situation. I really hope that the bug triaging activity I have seen helps to 
dig out those gems.

Thanks,
-- 
Martin



More information about the kdepim-users mailing list