On Tue, 11 Mar 2003, David Woodhouse wrote: > Evo _does_ generate unusually high traffic to the server. You select a > mailbox and it'll refuse to display _anything_ until it's got _all_ > headers for _every_ mail in that mailbox. You select a mail with a small > text/plain body and a _huge_ application/octet-stream attachment, and > it'll download the whole of the attachment just to run 'file' on it and > decide what options to put in the little drop-down menu associated with > it in the display. Etc.
Unfortunately, I've seen this type of behavior quite commonly with applications which take the point of view "IMAP is too limiting, therefore we'll just download the whole thing and do it ourselves." > You can't do client-side caching of > message flags at all, except for a folder while you've _actually_ got it > SELECTed, and you can't avoid actually polling _all_ folders which might > potentially have new mail -- you can't even use the \Marked and > \Unmarked flags in the LIST response to optimise away some of your > STATUS commands, because \Unmarked folders can have new mail you've > never noticed. This is a consequence of trying to maintain a complete synchronized client state of all messages in all mailboxes, so that, somewhere, somewhen, you won't have to go to the server to get it. I use online clients instead. Yes, I have several dozen mailboxes. But out of all those, only two are active -- that is, they can be expected to receive new messages. I also read about a dozen newsgroups, but STATUS is fast with NNTP (or NNTP via IMAP) so it's alright to poll. I use several clients, but I don't keep state on any of them if the client is not running. Thus, I don't worry about synchronizing with previous state. IMHO -- and YMMV -- far more work is done in unnecessary synchronization than is ever saved over what an online client does. I've tried many disconnected clients (which do synchronization) and each time, have gone back to Pine. > So I'm wondering if these problems have been fixed in subsequent IMAP > extensions I'm not yet aware of, or if in fact we'd need to 'fix' the > IMAP protocol first before I can properly fix up Evolution (or indeed > whatever MUA I end up with) to _really_ make me happy :) Any client which does not work with the IMAP base specification, and instead depends upon an extension, is ultimately doomed to failure. > Only now I seem to have upset Mark by mentioning that in an attempt to > alleviate the problem with excessive STATUS commands I switched from > wu-imapd to Courier, which probably wasn't a good place to start :) You didn't upset me. However, I am pointing out that you can easily get a distorted view of how IMAP is supposed to work if you use Courier as an example. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
