Re: POP3 "resume download" extension

> Thinking about pipelining, though, how does this sound: POP3 is normally a
> half-duplex-like dialog.  Suppose we allow an allowed a received command 
> sequence (like maybe "!NEXT") to queue an interrupt of the download at 
> the next chunk.  

If you're suggesting that servers do out-of-order command processing, 
I don't think that's the way to go.

The goal of pipelining chunk requests is to get maximum download speed
while still having an early abort capability.  Say a client is trying
to download a 1MB message in 100K chunks.  If it has to get the response 
from each chunk request before asking for the next the next chunk,
there's a round-trip delay after every chunk which could take as long
as downloading 100K of data.  So having partial retrieve could make the
overall download take twice as long.  OTOH, if the client can queue 
ahead several PRET requests then it can make sure that there is always
a request outstanding in the server's queue...so there is no waiting.
but it can still abort a download within the time it takes for the 
server to deal with the number of queued-ahead requests ... which is
much better than waiting for the entire message and (if tuned right)
also better than closing and reopening the connection.

maybe what is needed are two "special cookies" for PRET:

cookie # means "start at beginning of message"
cookie @ means "continue transfer following the last PRET"

however, this adds some state to the server.  what happens if a client
is displaying multiple messages from the same server in different windows,
and the user keeps scrolling the windows around?  the client (having 
initially only downloaded enough of each message to display the first
page or two of each) might then want to interleave PRETs from one message 
with PRETs from another.  

Keith

Keith