MBOX-Line: From guenther+imap at sendmail.com  Fri Jun 11 17:15:51 2010
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <4C12CACB.7030205@aol.com>
References: <1768814180.483.1276267238967.JavaMail.root@dogfood.zimbra.com>
	<1276267479.22134.102.camel@kurkku.sapo.corppt.com>
	<alpine.OSX.2.00.1006110910440.662@hsinghsing.panda.com>
	<1276274718.22134.138.camel@kurkku.sapo.corppt.com>
	<30B328B7-4D1B-4C7E-96CA-E37F7919E2A6@iki.fi>
	<alpine.OSX.2.00.1006111603200.662@hsinghsing.panda.com>
	<4C12CACB.7030205@aol.com>
Message-ID: <alpine.BSO.2.00.1006111652100.28689@vanye.sendmail.com>

On Fri, 11 Jun 2010, John Snow wrote:
...
> I've never understood how pipelining commands is useful.  If I were 
> writing a client, I would want to know the outcome of each command 
> before issuing the next.

The core bits of IMAP are that of a cache fill protocol.  The client 
decides it needs something and requests it, and then goes on and does 
whatever else it wants while the server sends the requested data.  Why do 
you want to block for each command's status when there's useful things you 
could be doing?  Yes, there are protocol operations where you don't want 
to continue until you know the result.  So you wait for those.  But for 
the majority of IMAP operations there's no need and no benefit.  Why do 
you want to know the result of a FETCH command before you issue another 
one?  How would you react that you cannot just do after you send the next 
FETCH?


Philip Guenther

