36 lines
1.6 KiB
Plaintext
36 lines
1.6 KiB
Plaintext
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
|
|
|