On Tue, 2003-03-11 at 20:28, Mark Crispin wrote: > 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."
Well, it's broken and it needs fixed. But if I'm going to sit down with a pretty GUI mail client and completely redesign its IMAP back end, I want to take some time beforehand and get it _all_ right rather than just fixing the stuff that's annoying me right now. Hence this discussion -- I'm trying to take the view "IMAP is too limiting; how can we fix it". > This is a consequence of trying to maintain a complete synchronized client > state of all messages in all mailboxes, Not entirely. I don't necessarily want a _complete_ synchronised state -- but neither do I want to have to discard the state I _do_ need, and download it again shortly thereafter, just because the server gives me no way to be sure that nothing's changed in the meantime. If I don't talk explicitly about reducing the amount of state required by the client, that's not because I don't agree it needs doing, but rather because that is a quality of implementation issue and just wants _fixing_ without discussion. But however little state we can get away with actually requiring, we still want to cache it wherever possible to avoid unnecessary traffic. > so that, somewhere, somewhen, you > won't have to go to the server to get it. I use online clients instead. Well, maybe. More fundamentally though, I'd say that this is a consequence of living on the wrong end of a 64K ISDN link and hoping that somewhere, somewhen, I can eliminate _any_ redundant traffic to the IMAP server. And redownloading message flags which I already had and which haven't changed is definitely redundant -- especially if it's doing so just because I temporarily selected my inbox to read a new mail therein, before returning to the mailing list I was reading a moment ago. Maybe I'm trying to solve a problem which isn't actually relevant to most people in the 'real' world where bandwidth is free -- I suppose I might be half-inclined to buy that argument. But there are a lot of parts of the world where bandwidth still isn't entirely free, and/or where mail servers are expected to be accessed over a WAN -- so maybe I won't buy it. > 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. I tend to keep coming back to Pine too, and have tended to use it as an example of 'ideal' IMAP behaviour. But it's not quite perfect either -- it _could_ cache headers locally but doesn't, and this means that sometimes it takes _seconds_ just to draw the screen after I hit PgUp in a message index, saturating my link while it's at it. My mileage _does_ vary -- I don't think caching is that overrated; I think you've been spoiled. :) I'm not talking about full disconnected operation; merely trying to reduce the total amount of traffic between client and server by intelligent management of changes. It's a similar problem to the one that UIDs solve. > Any client which does not work with the IMAP base specification, and > instead depends upon an extension, is ultimately doomed to failure. That's indisputably true. If I try to rewrite a mail client's back end so that it _relies_ on being able to cache stuff using a new IMAP extension, you have my permission to come over here and shoot me. Repeatedly if needs be; till I stop it. But that doesn't mean we shouldn't think about an extension which can allow optimisation of client<->server traffic in the happy situation where both server and client _do_ support it. > > 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. A fair point, and I'll bear it in mind -- thanks. To be honest, I'm trying to avoid paying too much attention to the server side right now. There's plenty for me to do just trying to get optimal behaviour from the _client_, and I'm _assuming_ the server gets it right; or at least so much closer to 'right' than the client that it makes no odds :) In general that tends not to be too far from the truth because designing GUIs seems to rot the parts of the brain that really care about efficiency. :) Switching servers did give me a fairly significant performance improvement for all those STATUS commands which I can't see any reasonable way to avoid given the current definition of the IMAP protocol, but I have no qualms about switching again if (or when) Courier also turns out to upset me :) -- dwmw2
