GNOME Bugzilla – Bug 237499
Display pauses during IMAP mail download
Last modified: 2006-05-09 20:17:58 UTC
When viewing mail from a distant and slow imap server, Evolution will download the whole mail before rendering _any_ of it. This is very suboptimal -- in the case of plain text, at least, we should be rendering the text as it arrives, giving the user the chance to delete or refile the mail, and/or move on to another mail, as quickly as possible. Similarly, Evolution takes ages to exit while it's downloading a huge (multi-megabyte) mail. It would be better to use repeated partial downloads than to ask the server to spew a huge mail at us and then lock up while we wait for it. And even in the latter case, we should at least be rendering it as it arrives.
I don't think this is feasible, but it's up to mailer hackers to resolve.
It should be perfectly feasible. Refer to RFC2060, section 6.4.5 (FETCH Command): It is possible to fetch a substring of the designated text. This is done by appending an open angle bracket ("<"), the octet position of the first desired octet, a period, the maximum number of octets desired, and a close angle bracket (">") to the part specifier. If the starting octet is beyond the end of the text, an empty string is returned. There should be relatively little overhead in fetching the mail in chunks of 4KiB, rather than blocking the connection to the IMAP server by requesting it _all_ at once. And even if the server doesn't support partial fetches (although I think it's mandatory now, it may not have been in earlier IMAP specs) you can still _render_ the mail as it's arriving, rather than waiting for the whole thing to arrive before you even begin. Stick a mail with huge attachment on a remote IMAP server, try looking at it with pine. Observe that it renders the _text_ as it gets it, and doesn't download the attachment at all unless you want to save it. Try same with Evo. Observe the difference in usability.
I suppose if we had some sort of special fetch-as-we-read imap stream might make this doable... but we do need the entire CamelMimeMessage object before we can pass it off to the rendering code... marking as future since I don't see us getting to this anytime soon.
although this is a worthy goal, even with an ideal imap implementation it is basically impossible for all parts. text/plain parts will never be displayed incrementally: - we always need to scan the whole text part *before displaying anything* to look for inline uuencode/ps/pgp/binhex content. - we usually need to scan text parts for invalid/misnamed character sets before we can display them. for other parts however, e.g. properly labelled pictures and the like, it would certainly be doable. maybe even for html.
this also depends on imap servers actually working with this feature. considering how often we've hit bugs in imap servers just requesting a subset of the headers, I'm a bit skeptical that we won't have problems with this imap feature :-\
closing as WONTFIX because of the last 2 comments - just not worth it.