Re: Years later, kmail still is not a viable email client?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Well, problem is that Akonadi is responsible for storing, indexing, searching 
and presenting data. Which is like 90% of what mail clients are actually 
doing. This means that It is actually almost the same amount of work to write 
new email client from scratch then to remove akonadi from KDE PIM. Therefore 
if kmail does not work for a user (it works for me perfectly fine) why he 
would insist to rewrite kmail instead of simply using other "lightweight" 
email client? Rewrite is not guaranteed to be bug free, in fact at least 
initially it would probably be very buggy which would actually downgrade 
experience of fortunate current users satisfied with the software.  

René J.V. Bertin pisze:
> 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.






[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux