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.
