Re: POP3 "resume download" extension

Keith Moore wrote:

> what I had in mind was being able to download a message in chunks with a
> fairly easy way for the client to say 'stop sending any more chunks'.
> having the client close and reopen the connection is slow and wasteful.
> so if the client can ask for (say) the first 50k, then the second 50k,
> etc. and the user wants to stop downloading after a few seconds, then
> all the client has to do is stop asking for more chunks.  but it seems
> like you do want to be able to pipeline it.
>

Yes, I see what you mean.  I agree that punting the connection seems inefficient.
You could also do such a thing as a RETR extension, but it would be sufficiently
incompatible that it wouldn't really be any different from a separate command.

Pipelining this sounds hard.  It would be cleaner to check the size of the messages
before beginning the RETR, thereby deciding what exceed your threshold.  However, I
suspect that a user wouldn't always see it that way.  Sometimes you end up on a
clogged channel or a slow connection that you don't expect.  So we need to look at
the problem strictly from the user abort point of view.

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.  This
would require the server to at least nominally *listen* while sending, but since it
would not have to process it until the next chunk-boundary was reached the listening
would not be too onerous.  How difficult would something like this be to implement?

Chris