kde-pim dev needed, for a sponsored open source effort, to remove akonadi

[E. Hakan Duran]

Dear all,

I have no background in software development other than a personal hobby level and therefore I am not a candidate for Pauls' job offer :). I have been a Kontact/Kmail user since KDE 3 though. The reasons why I loved this suit were its speed, graceful handling of pgp/gpg, clean and customizable interface. I used to have a (heavy!) Toshiba laptop dual booting with Windows XP at the time, and I would use Outlook Express on the Windows side of things as compared to Kontact/Kmail with Mandrake/Mandriva linux. The comparison was very simple then, with Kmail/Kontact being far superior in truly every respect. Outlook Express would freeze the whole system if you happened to decide using it for usenet news for example. For several seconds, up to minutes; even the mouse cursor would not move sometimes. Switching to another news group would likely repeat the whole experience. Kmail/Kontact on the other hand was very responsive, would never strain the system no matter what you threw at it, and advanced customization was usually as easy as finding the right line in the right rc file, which there weren't really many.

Many truly valuable and trustworthy devs think that a database backend is far superior for a PIM suit. I trust them and I don't have a reason to try proving otherwise. My perspective is the simple user experience, which was quite traumatized during the transition I lived over the course of last 10 years or so. Currently, I use KDEPIM on my desktop PC only; I prefer and have the luxury to be able to check my emails using the web interface from my laptop. Since I don't expect encrypted email from my work account, I can afford that. I have used KDEPIM/Akonadi on Mandriva, Fedora and Arch linux and experienced that every distribution had some different variation of problems with akonadi. I have been using Manjaro linux for the last 4-5 years, and I believe both because KDEPIM/Akonadi now reached to a more mature state, and perhaps also because Manjaro folks did a better job in incorporating it to their distribution, I think it is pretty usable on a desktop PC. I would not install it on my laptop due to system and battery abuse potential as reported by Paul's previous email.

My 2-cents worth opinion is that the tools needed to make a PIM suit work with a database backend were truly not available when this decision was made. Nepomuk, strigi, baloo, akonadi have different associations for me than say vi, gpg, bash. While the latter are meant to represent a stable, dependable and do-the-job-right-at-the-first-time kind of software, the former represent everything but those. And when the foundation is not stable, this is what you get. Since my thoughts are just from a user perspective, my conclusion may not be very accurate, and I apologize if I offend any dev due to those. However, as good as it sounds to start anew, with even a better backend or infrastructure design plan, it needs to be remembered that one has to have the right tools for the right job. If the right tools are not available, either they should be developed first, or the design should be kept simpler until those tools are available and stable enough.

I am sorry to occupy your inboxes with my long blabbering. Thank you for reading. Thank you for your initiative Paul and please keep us informed about how it moves forward.

Hakan Duran

On Friday, March 16, 2018 4:18:47 PM CDT Paul Vixie wrote:
> so there are two things i am unclear on, wrt akonadi's problems.
> 
> looked at: https://marc.info/?l=kde-pim&m=151777761106658&w=2
> 
> question 1: how did it ever get this bad? clearly the design and 
> implementation was not stress tested or stringently reviewed.
> 
> question 2: why would we stress test or stringently review a fix, given 
> that akonadi + kde-pim as it is, wasn't tested or reviewed, and is 
> unusably bad?
> 
> background:
> 
> i have to shut down kmail and akonadi whenever i'm not reading e-mail, 
> to keep it from eating my 12-hour battery in 45 minutes, and to protect 
> my network bandwidth. when i start it back up i have to do it in a very 
> particular order since only the first imap connection to come up will be 
> able to do IDLE, and the kolabsys imap server _only_ works if you do 
> IDLE. and then akonadi has to check _every single folder_ to find out if 
> anything has changed. and then if anything has changed it has to 
> re-download _every single message_ in that folder. including trash, 
> which usually has thousands of messages in it. so i'm in it for a 
> minimum of a gigabyte of bandwith and 15% of my battery just to start 
> kmail back up, which i have to do whenever i receive encrypted e-mail.
> 
> conclusion:
> 
> my view is, don't ask for second set of eyes on code or testing, just 
> commit patches to make akonadi better, because nothing you can break 
> that way would be worse than the current situation.
> 
> vixie
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20180316/d6aac027/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20180316/d6aac027/attachment.sig>