[Bug 82684] allow for IMAP message cache customizability

Lloeki lloeki at gmail.com
Mon Mar 10 09:55:36 GMT 2008


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=82684         




------- Additional Comments From lloeki gmail com  2008-03-10 10:55 -------
for me, dIMAP is slow for two reasons:
- it "acts like pop3" i.e it fetches all messages, content, attachments, etc...
- it synchronizes slowly, making many connections checking thoroughly what has (not) changed and sending new message status, the latter being excruciatingly slow: it can take up to 5 seconds to upload a 'read' status of one single message (this is not due to network issues).

what's more if I have a mail reading session, I must hit check 'retrieve mail' two times:
- once for checking mail in
- once for commiting any change I made if I want them to be seen by another client (phone, webmail) I may connect to in the meantime

all of those issues make dIMAP particularly time consuming and inefficient, especially in a non-persistent, mobile connection scenario when connectivity is both varying in quality and quantity.

classic IMAP in its current kmail implementation is out of question in such a use-case too, because it is totally connectivity-dependent. many bug reports have been made here to have a coherent and configurable caching solution in classic IMAP, readable offline. most of the answers were brutal bug closures (certainly due to bug triaging) or recommendations to use dIMAP.

I suggest to see how e.g claws-mail handle IMAP wonderfully (I suppose, reading the above, that thunderbird behaves somehow the same), respects the offline status and allows for cached mail reading nonetheless.

added to this, and more in line with the current bug report, it would be very interesting to have the possibility to define exactly what should be fetched from the imap server (headers only, headers+maximum content size, header+body+attachments or not) and at which time (upon 'check mail in' or upon actually reading the mail for which only headers would have been fetched when 'check[ing] mail in'), the full message being downloadable via a menu entry and a toolbar button.



More information about the Kdepim-bugs mailing list