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

> 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.

That sounds horrible. Are you sure these issues are due to the Akonadi 
(database) backend? It may also be the kolabsys and/or kimap resources. In 
my experience, the IMAP backend is a bit weak functionality and 
performance-wise. (No experience with kolab.) Perhaps pay someone to first 
unambiguously help identify the underlying issue?

If it is kimap, there is a kimap2 in development that I though would 
replace kimap at some point. It seems this is being worked on by the people 
working on sink/kube. I'd always hoped they'd use the Trojitá IMAP code, 
which is first class. (Give Trojitá a try if you want to experience how 
good an IMAP client can be performance-wise.)

> 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.

Hmm. From your experience this is probably true, but for me it has been at 
least two years since I had serious performance issues with Kontact. (I'm 
using an IMAP resource w/37k messages, some *DAV resources, with a mysql 
database.)


Success,

Erik