Re: Yet Another Troubled KMail2 Migration Successful (Maybe) (For Now)

On Fri, 5 Jul 2013 01:07:04 PM Jerome Yuzyk wrote:
> But speaking of Reality, the reality of KMail2 is that it's trying to do 
> something real hard like concurrent transaction consistency with a 
> distributed part-time volunteer workforce. Unfortunately e-mail is a 
> pretty central and already-solved-reliably function in all our lives, and 
> not a good place to have us all experiment on the fly with middleware and 
> its need to maintain Reality for us. 


I've found kmail2 quite good for handling my large (100,000+) gmail account, 
have re-registered it on many desktop tests and rebuilds. The features and 
integration are very good.

But:

- Its IMAP, so I've never needed to import old data

- all my filtering is done server side by gmail, so I don't use client side 
filters

- I don't do bulk operations client side (except for marking emails read) . 
I've never tested moving several thousand emails from one folder to another. 
The marking of large amounts of emails read used to be unreliable until recent 
fixes in master, I find it quite good now.

- While *much* better that it used to be, there are still issues with blocking 
calls preventing already cached emails being displayed. I suspect that will  a 
problem somewhere down in the akonadi layer.

- I've given up on search, except for the msg list filter. Nepomuk continues 
to be an ongoing train wreck. I'm convinced the underlying tech is over 
complicated and over engineered, and the fundamental design is flawed. The 
logging and error reproting is erratic making actually tracking down issues 
difficult. Looking in the code there is a a lack of sanity checking on inputs 
and a lack of checks for error returns and "impossible" cases which makes for 
random and inconstant bugs. It handles errors very poorly, resulting in 
searching accross the board (desktop, files etc) being unusable.

Plus a chronic case of "Not Invented Here" syndrome. There are a number of 
mature stable general full text index engines such as xapian that could have 
been used from the start. Recently the developer decided not use the document 
filters in okular, deciding to roll his own instead. Wasted, duplicate effort, 
classic reinvention of the wheel.

The whole thing smacks of  students wanting to play with new tech instead of 
the boring work of actually creating a working product. I have no faith that 
it will ever be reliable.
-- 
Lindsay

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEABECAAYFAlHXYEIACgkQNbLM9wS4sYee6ACg07RHaGY4RRC8KQUUutFOZp2p
KIwAn0/QJ3SiJHuxzDOPu0zBy2zpg+zn
=EWtq
-----END PGP SIGNATURE-----