On Tue, 11 Mar 2003, David Woodhouse wrote:
> I'm trying to take the view "IMAP is too limiting; how can
> we fix it".

That's not the right view.  You should instead have "how can I build a
good client within the context of IMAP, without expecting the existing
IMAP world to add facilities to enable me."

> 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.

I keep my IMAP clients (at least, one at home and one in the office)
running for days at a time.  I have two incoming mailboxes and some
newsgroups.  All other mailboxes are ones that get updated by my action.

> 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.

I once regularly used IMAP over a 2400 bps line, and to this day I still
use IMAP over a CDPD device.  Please do not treat me as someone who
doesn't understand the issue of slow lines.

My claim is not that you should re-download data that you already had.
Rather, you should not re-download anything unless you need it; and by
following a strict "don't need it, don't download it" will buy you more
than efforts to keep the caches of a dozen clients in synchronization with
each other.

> 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.

So why didn't you spawn a separate session for the other mailbox?  TCP
sessions are cheap.

> 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.

I have never had it take more than a second or two, even with CDPD.  It
all depends upon the size of the envelopes.

Have you noticed that Pine *does* completely cache within a session?  As
long as you don't give up the session, Pine will never re-fetch the same
data.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Reply via email to