The KDEPIM / Akonadi situation (was: Re: Showing respect)

[Philippe Cloutier]

Hi Martin,

Le 2020-06-12 à 16:49, Martin Steigerwald a écrit :
> [...]
>
>
> For me part of the answer meanwhile is: It appears to be pretty damn
> hard to get Akonadi right. Simple as that. Whether that is due to its
> architecture or other reasons I don't really know, but I believe the
> architecture of Akonadi to be a part of the answer.
>
> Cause frankly, when I truly think what a suite of PIM applications mean
> to me with a user hat on, I'd say something like "akonadictl fsck" is a
> bug already. Seriously, fsck my mail program? If I truly think this
> through I have *no* idea how to explain this to someone who just wants
> to use it. Never ever in my whole live I fsck'd a PIM application
> before.


I wasn't aware of akonadictl fsck. Thanks for pointing that, and I 
understand very well what you mean, but my experience/misfortune forces 
me to dispute this point. Even the most famous (and probably most 
funded) PIM software has an equivalent called SCANPST, and it is 
actually required in my experience. I had to use it with Outlook 2003 
hundreds of times, and it's not gone in the newest versions. And despite 
its name, it's also relevant for the newer file format (OST): 
https://support.microsoft.com/en-us/office/repair-outlook-data-files-pst-and-ost-25663bc3-11ec-4412-86c4-60458afc5253?ui=en-us&rs=en-us&ad=us

So without saying there is no room for improvement there, we can't 
really single out Akonadi just for that. I researched the topic a bit 
and according to what I see on Wikipedia, NTFS would be the only 
filesystem to feature transactions: 
https://en.wikipedia.org/wiki/File_system#Transactional_file_systems
Plus, the feature is deprecated, so I'm afraid filesystem integrity will 
remain problematic for quite some time: 
https://en.wikipedia.org/wiki/Transactional_NTFS


That being said, I am not saying KDEPIM (widely speaking) can't be 
improved. I personally gave up on KMail more a decade ago after seeing 
enough reports of serious issues and experiencing so many issues myself 
that I haven't even been tempted enough to give it a new try yet. And 
nevertheless, I still have serious issues with all KDEPIM applications I 
still use, i.e. KNotes and KOrganizer. One which may be related to 
Akonadi was reported years ago. I reported quite a few more last year, 
even largely providing the solution to some, but in all cases, to my 
knowledge there was no progress, even though I mentioned some of these 
issues in messages sent to this very list, most recently 
https://mail.kde.org/pipermail/kde-community/2019q4/005921.html

I don't know much about community goals and what setting one entails. 
"Fixing KDEPIM / Akonadi" doesn't sound like a low-hanging fruit, but 
that doesn't mean the benefit–cost ratio wouldn't be high.
I have no clue about Akonadi's architecture and don't know much about it 
in general. I don't know if Akonadi should be rewritten, but if it 
should (and that's a big "if"), I would agree with prioritizing that 
over writing a new sound player, a new text editor or a new window manager.
I don't know if this should be a community goal, but I think properly 
tracking KDEPIM / Akonadi issues would be a good start (achievable for 
much cheaper than rewriting Akonadi) making it easier to decide whether 
a rewrite is needed and to what degree such a goal should be prioritized.

> [...]
>
>
>
-- 
Philippe Cloutier
http://www.philippecloutier.com