39 lines
1.5 KiB
Plaintext
39 lines
1.5 KiB
Plaintext
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.
|
|
|
|
|