Akonadi disaster

[Martin Steigerwald]

Am Mittwoch, 5. Oktober 2016, 15:24:19 CEST schrieb Wolf Drechsel:
> > > Can we just get rid of Akonadi, Xapian, MySql and so on and have  
> > > plain simple maildir/mobox.
> > > 
> > > I know absolutely noone that search for mails outside their mail  
> > > app, be it Outlook or whatever.
> 
> I left KdePIM more than a year ago for the continuous akonadi trouble.
> Recently I tried to come back, but still these things seem to be
> persistant - my first step was to make my CalDAV client work, and I got
> stuck there, syncing with owncloud failed from the very beginning.
> 
> KdePIM (Kontact) is a really great piece of software, IFAIK unique in
> in *nix world, really powerful, hardly lacking any features. It's such
> a pity that this wonderful product is pulled down so much by the
> akonadi problems.
> 
> I really appreciate the hard work all the people put into akonadi, and
> I absolutely understand that it would be hard to dismiss all that work.
> 
> But - to achieve a useable product, wouldnt it be a good idea to create
> a second branch "non-akonadi" of Kontact? - Maybe a little less
> performant, but reliably working very soon. You know that there's a guy
> called Pali (and probabely some other people), who got ahead with that
> idea:
> 
> https://launchpad.net/~pali/+archive/ubuntu/kdepim-noakonadi
> 
> Maybe the akonadi option is one for the long run. But during the last
> year, obviously that beast could not be domesticated.

Its really interesting how much experiences differ.

For me the current Akonadi is the best one I ever had. It never has been this 
fast and reliable. Is it perfect? No. Does it have still some issues? Yes. 
Does it still have areas where it is highly inefficient? Yes. But its better 
than any Akonadi I had on this laptop so far. Way better.

That is my experience.

> Let's do a try to the "without" approach!

Pre-Akonadi KMail has its own set up partly quite serious issues. Like for 
example…

not starting up for *minutes* and more on index file corruption since it first 
rebuilds the index files, but also …

doing all of the mail handling within KMail itself and thus blocking out 
KMail.


Granted, even with Akonadi´s single-task at a time, this can still happen, but 
with most recent Akonadi versions its way less annoying for me.


I agree tough that Akonadi needs more improvement. Its still not as stable and 
reliable and as fast when it comes to latencies regarding user requests as it 
should be.


I still use KMail nonetheless, cause well I didn´t have an Akonadi crash in a 
very long time… and I see no viable alternative to KMail. For me KMail just 
crushes every other GUI based mail client I tried into pieces in terms of 
features, usability and working just in the way I like it to.


Anyway, for any users who wants to try out other MUAs, do it. Especially if 
Akonadi doesn´t work for you.

But if you want to see Akonadi fixed a "it doesn´t work, remove it from KMail" 
to upstream is just not going to work. Upstream was very clear that KMail will 
continue to use Akonadi *unless* another backend becomes more viable. And I 
think upstream still has this oppinion. Maybe at one time the new Akonadi 2 => 
aka I forgot the new name that Kubemail uses. But not just yet. Maybe not even 
in half a year or year.

So when you want to continue to use KMail, for now you have to deal with 
Akonadi. Or rely on third party efforts to maintain and develop an akonadi-
free KMail.

Honestly, I rather stick with upstream. Upstream KDEPIM already has few 
developers. But at least a few are paid to work on it. A fork of KMail is 
unlikely to have more developers behind it and may not even have even one paid 
developer behind it.


So to conclude this mail:

I think that any mount of requesting "make KMail not use Akonadi" is a 
complete waste of energy and time and has no potential to change the situation 
of the one who does the requesting.

Thanks,
-- 
Martin