GNOME Bugzilla – Bug 222499
Requires downloading all headers before displaying
Last modified: 2005-08-22 04:21:46 UTC
Description of Problem: Evolution needs to download all headers for an IMAP folder before displaying them. If you have a slow connection or a lot of messages (or both) this could be a real problem. Steps to reproduce the problem: 1. Click on a folder with a lot of messages (>1000, for example). Actual Results: Evolution doesn't display anything until all headers are read. If you have a lot of messages (I have some folders with 10,000+ messages in my mailing list archives) this can take a while. Of course, it'll take even longer if you don't have a fast network connection to the server. Expected Results: Display headers as they're downloaded. Or download only enough hearders to fill the first screen, then download the rest in the background. How often does this happen? Additional Information:
this is non-trivial, maybe in some future version... like 6.0 :-)
Well, most of camel could probably deal with this, but the increemntal update (adding messages bit by bit) is really really slow (because of bugs in the table widget we need to rebuild the whole list every time). Things like threading dont work very well either as new messages upset the display. We should probably have an option for 'fast summaries' which would mean threading wouldn't be as reliable, and 'vfoldering or searching on mailing list' would also be much more limited. This option would just used a an IMAP "BODY" request to get the headers, and be significantly faster. (this is separate from incremental message-list updates). Marking as dependent on the imap rewrite, to track it and keep it in mind.
fwiw, my imap reqrite no longer even fetches headers, it fetches envelopes which are like 1/3 or less of the header sizes so this is even less needed now.
*** This bug has been marked as a duplicate of 260167 ***
Wrong duplicate
this bug is about IMAP, a related one is bug 201718 about showing emails immediately in the message list after downloading them by POP3.
imap or pop (or nntp for that matter), the problem is actually at another layer of the code, so not imap or pop specific *** This bug has been marked as a duplicate of 201718 ***