I have a machine at work with a slow (60ms RTT) NFS connection which hosts my home directory. Running kmail/Akonadi against this is nearly unusable and frequently is unable to load emails when I select them. One proposal I have seen is to change the XDG_DATA_DIRS environment variable or similar. This has 3 problems: 1) Changing that variable potentially impacts more applications than just kmail/Akonadi 2) An individual machine may not have any local stable persistent storage. 3) I want my personal data to be persisted as well as to be sharable / accessible on other machines. That is: I'm using NFS for a reason. One method I can see for improving this architecturally is to split Akonadi internally to have separate storage locations/engines for what I'll refer to as cached data and authoritative data. From the page here: https://blogs.kde.org/2011/11/13/akonadi-misconception-1-where-my-data I'm using "cached data" to refer to data which is persistently stored outside of Akonadi as the authoritative source. So this would be copies/information about mail stored on an IMAP server, or that which might stored in a Maildir locally. I'm using "authoritative data" to refer to data for which Akonadi is the sole owner. This includes "metadata added to your data", "Nepomuk tags", or "data that is not yet syncronized to the server". This is data I do not want to lose. By separating the storage for the cached vs. authoritative data, I could have the authoritative data stored on a high-latency NFS server while the cached data is stored locally on-disk or in memory. There may be other solutions - this is merely one idea I've come up with. Reproducible: Always Steps to Reproduce: 1. Configure user with NFS home directory with high latency, potentially with occasional random packet loss. 2. Configure kmail/Akonadi to point to existing IMAP server with lots of email. 3. Enjoy the unusability. Actual Results: Kmail frequently stalls trying to retrieve my email. Selecting a particular message frequently stalls indefinitely at "Retrieving Folder Contents Please wait ..." message. Similar to: https://bugs.kde.org/show_bug.cgi?id=289097 Expected Results: I am able to select email and have it visible within a handful of seconds consistently. My data should be persistent.
This bug has never been confirmed for a Kontact version that is based on KDE Frameworks, except possibly a Technology Preview version 5.0.x. Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the opportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12; preferably much more recent), please open a new one unless it already exists. Thank you for all your input.