MBOX-Line: From tss at iki.fi  Tue Aug 31 08:16:12 2010
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] "Multiple Commands in Progress" real life
	support and ambiguity questions
In-Reply-To: <2721.1283156569.612563@puncture>
References: <4C7A2AB6.6070405@lists.grepular.com>
	<alpine.OSX.2.00.1008291038500.370@hsinghsing.panda.com>
	<2721.1283156569.612563@puncture>
Message-ID: <1283267773.6489.449.camel@kurkku.sapo.corppt.com>

On Mon, 2010-08-30 at 09:22 +0100, Dave Cridland wrote:
> On Sun Aug 29 19:31:58 2010, Mark Crispin wrote:
> > Few, if any, IMAP servers will execute commands out of order.
> > 
> I don't know of any for certain, but if anyone's implementation does,  
> it'll be Arnt/AMS's.

If a command starts blocking on client output (like a large enough
FETCH) then Dovecot starts running the next command. There are a few
advantages, although possibly small enough that they don't matter:

1. Less latency, because any disk I/O is started while the previous
output is still being sent to client.

2. Kernel might be able to reorder disk I/O better since it knows more
what data is going to be read.

3. Maybe the client wanted to do a couple of STATUSes in the middle of a
large fetch, and could update the UI faster while FETCH is still going
on..

Of course, 1-2 can also be implemented by starting the commands but
delaying/buffering client output, and clients can do 3 with another IMAP
connection.


