The KDEPIM / Akonadi situation (was: Re: Showing respect)
Philippe Cloutier
chealer at gmail.com
Sun Jun 28 14:49:15 BST 2020
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
More information about the kde-community
mailing list