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
