On Monday October 12 2020 13:15:52 Marek Kochanowicz wrote:
>As for the importance of the akonadi: it is actually a well designed piece of
>software architecture
There are actually multiple levels at which you can come to that conclusion
>that simplifies all PIM apps drastically.
This being one of them.
Sadly that doesn't exclude the possibility of there being design flaws or inadequacies at other levels.
Taken as a whole it's an extremely complex system that clearly cannot be guaranteed to work reliably for everyone and in every situation, and the more complex it becomes the larger the chance that something's been overlooked or, on the contrary, patched without considering all possible consequences of the "fix", etc.
For instance, the version I'm using doesn't like the host being suspended nor when a remote server becomes unavailable. Quitting Kontact before suspending the host helps but there are still periods where things are less stable. Those may or may not be related to my desktop session having become old and top-heavy (so IPC isn't as smooth as it could be).
>Removing
>akonadi from PIM is not only (IMHO) pointless but also prohibitively expensive
>endeavor.
IMHO it could be worth investigating just how much work it'd be to cut out the akonadi server architecture from KMail (and KMail alone). Cf. kwallet: apps can either access wallets directly & in-process ('synchronous' mode) or they can use async. access that goes through dbus and the kwalletd. The API is very similar, except of course you don't need implement the async communication overhead in sync. mode. If akonadi is indeed so well written the API used by the client (KMail) to get things done through the server is probably very similar to the API used by the akonadiserver to talk with individual agents, and maybe already provided in a shared library.
I cannot help but think of Quicktime here. That too was a pioneering framework that was very well written (at least when you looked at its individual components) and it simplified writing multimedia applications drastically (even using C). Yet Apple felt the need to replace it completely. The big difference is that this wasn't appreciated by users and (most, I presume) developers. (I'm not convinced AVFoundation has gained feature and flexibility parity even after all these years.
>Instead I would try to investigate what is the actual problem with
>the packaging and try to seek some kind of remedy for it.
Packaging cannot be the sole culprit.
If I'm not mistaken the test for that should be rather simple: recruit a sufficiently large and representative user population to run the flatpak build.
R.
