<div dir="ltr"><div>Hakan, you're so right. That's exactly my experience. I loved KDEPIM before akonadi. I also liked what they promised that akonadi could be.</div><div><br></div><div>But I didn't get akonadi to work reliable here. No special setup, just IMAP in the beginning. As I needed a reliable solution I moved to thunderbird years ago. It simply works. No need to be any DB admin. No need to think about what DB to use. No need to tune any DB engine. No need to know any workarounds to get akonadi back on track again.</div><div><br></div><div>As you can see, I'm still subscribed to this mailing list. Every now and then I try the latest release because I like KMail's and Kontact's usability. But to be true, I never dared to move back to KDEPIM because I can't forget the data-loss I had while testing. By reading this mailing list I have no hopes it could work better for me. Sorry.</div><div><br></div><div>I really don't want too negative and I *really* appreciate all the works anybody brings in KDEPIM, KDE and Open Source in general, but I personally lost faith in akonadi.</div><div><br></div><div>Happy new year 2021 and best regards,</div><div>Andreas<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 31. Dez. 2020 um 17:56 Uhr schrieb Hakan E. Duran <<a href="mailto:ehakanduran@gmail.com">ehakanduran@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have used KDEPIM since KDE 3.5 I believe. When the transition to<br>
akonadi was first introduced/discussed, I remember the argument was that<br>
once the optimizations were realized KDEPIM would integrate with the DE<br>
better and the experience would be more natural. I also heard several<br>
arguments about how an akonadi backend was the conceptual right choice<br>
for this purpose. I do not have a technical background and I respect<br>
those people, who were saying these. I still believe that they know<br>
better than me, and they probably have a lot valid points in those<br>
arguments. What I did experience personally was pain and suffering, with<br>
a long time of patient waiting for things to evolve into that utopia<br>
that was promised. There were times improvements were visible, there<br>
were times they weren't. After more than 10 years' time though, I<br>
concluded that KDEPIM with the akonadi backend did not provide me the<br>
experience that I loved with KDEPIM 3.5. I don't think it will ever do<br>
that; 10+ years is a long time. It was time for me to move on and I<br>
don't regret that decision. I do understand those who would like to<br>
stick with it further and don't blame them; I was one of them for so<br>
long. I am still a subscriber of this group for heaven's sake. However,<br>
I cannot deal with database administration for my emails, that is too<br>
much to ask from a user; I agree with Martin.<br>
<br>
Regards,<br>
<br>
Hakan<br>
On 20/12/31 12:39PM, Martin Steigerwald wrote:<br>
> Anders Lund - 31.12.20, 12:25:53 CET:<br>
> > torsdag den 31. december 2020 08.49.36 CET skrev Paul Vixie:<br>
> > > while i agree that pgsql's upgrade process could be simpler<br>
> ><br>
> > An easy way is to just delete the database. Akonadi will then create a<br>
> > new, functional one. Maybe evil - but simple. Works for me, with mail<br>
> > stored on IMAP and contacts and calendar on nextcloud. :)<br>
><br>
> Unfortunately Akonadi is not just a cache as I understood it initially.<br>
><br>
> For IMAP a mail that it could not yet store onto the IMAP server due to<br>
> whatever may just sit in the database. To my knowledge possibly<br>
> indefinitely as Akonadi would not try again. That are those payloads<br>
> without remote id.<br>
><br>
> For POP3 with local folders AFAIK this can happen as well. On top of<br>
> that filters you defined would point to invalid folders after recreating<br>
> the database. Meanwhile KMail seems to detect that and it will ask to<br>
> select the folder for every filter, which can be tedious, if you have<br>
> many.<br>
><br>
> I defended Akonadi many times. Meanwhile I think there are just too many<br>
> conceptional issues with it, that I think it may be beneficial to re-<br>
> think all of it and start from scratch. But that is a major undertaking<br>
> as well.<br>
><br>
> I think it is too much to ask from the user of a PIM suite to deal with<br>
> database administration tasks of any kind. And now, IMHO an automatic<br>
> update of PostgreSQL from Akonadi is not going to solve it. Especially<br>
> as there are many failure points for such an automatic update, if you<br>
> ask me.<br>
><br>
> I am using Evolution at work due to Office 365 and EWS plugin just being<br>
> so much more reliable for Evolution. I never ever dealt with how<br>
> Evolution stores mails. Actually I do not even know it. IMHO that is how<br>
> it is supposed to be.<br>
><br>
> Best,<br>
> --<br>
> Martin<br>
><br>
><br>
</blockquote></div></div>