MBOX-Line: From dave at cridland.net  Thu Sep  8 08:26:05 2005
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] SELECT of same mailbox
In-Reply-To: <Pine.WNT.4.64.0509071441180.3720@Tomobiki-Cho.CAC.Washington.EDU>
References: <8613FB1A1827570EC6B5150F@ninevah.cyrusoft.com>
	<Pine.OSX.4.63.0509071108110.28350@pangtzu.panda.com>
	<DC4E58A90D144DDA3A10024D@ninevah.cyrusoft.com>
	<Pine.WNT.4.64.0509071235060.3496@Shimo-Tomobiki.panda.com>
	<20596.1126126367.510966@peirce.dave.cridland.net>
	<Pine.WNT.4.64.0509071441180.3720@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <21888.1126193165.687819@peirce.dave.cridland.net>

On Wed Sep  7 09:08:03 2005, Mark Crispin wrote:
> On Wed, 7 Sep 2005, Dave Cridland wrote:
>> Another amusing thing with SELECT - when does the server change 
>> state for an OK or NO? When it sends the tagged response, or prior 
>> to that? If, given a client in selected state on mailbox Foo, 
>> something like:
>> C: A01 SELECT Bar
>> S: * 50 EXISTS
>> S: [...] Normal SELECT untagged responses, including another 
>> EXISTS.
>> S: A01 OK
>> Is that EXISTS for Foo, or Bar? And how does the client know?
> 
> Indeed; this is a known wart in the protocol.  It's an important 
> reason why no server generally sends responses when no command is 
> in progress, the main exception being the BYE untagged response.
> 
> 
Indeed. Which I think is a shame.


>> It is, of course, a completely legal time for the server to send 
>> an EXISTS for Foo, since it's allowed to send those when no 
>> command is in progress - it might have simply crossed on the wire. 
>> The only way to process that EXISTS would be to hold it until we 
>> either see no others before the tagged OK (in which case, we know 
>> the SELECT worked, and we can process it for Bar), or we see 
>> another (in which case... Which is for Foo and which for Bar? One 
>> assumes the first response is for Foo).
>> The same applies for PERMANENTFLAGS, FLAGS, and presumably other 
>> responses that SELECT sends.
> 
> Most clients don't go to that length; they simply assume that any 
> responses to SELECT apply to the selected mailbox.  Or they avoid 
> the problem entirely by never recycling a session (that is, they 
> never issue a new SELECT or EXAMINE in a session).
> 
> 
Since my client is aimed at using minimal bandwidth, and the setup 
cost for a new connection is far from small, then I do recycle 
sessions as much as possible. As far as I'm aware - and I've not 
looked into this very much - my client will cope with this particular 
issue.

>> As it happens, I know of no server that sends any responses when 
>> no command is in progress, but RFC3501 specifically advises that 
>> this is possible.
> 
> Some people though that it was vitally important to have responses 
> when no command is in progress otherwise "IMAP will die" (a similar 
> campaign was waged about multiple commands in progress, as opposed 
> to pipelining). That experience reinforced my general disdain of 
> arguments of the form "IMAP must do <X> or IMAP will die."
> 
> 
I think both - multiple commands in progress and responses when no 
command is in progress - can help make the service more responsive. 
On a multithreaded server, it's perfectly possible to do both.

I don't think IMAP will die if this isn't done, obviously, but I do 
believe it helps. I've implemented both responses when no command is 
in progress and multiple commands in progress on both client and 
server in ACAP.

It makes the usage of a single connection much more responsive, as 
large pipelines do not build up as large a round-trip time for the 
last command. ACAP obviously requires the "responses when no command 
is in progress" item, and its usage of tagged intermediate responses 
solves much of the problem with multiple commands in progress.

In IMAP, the situation is made more complex by the lack of tagged 
intermediate responses, but nevertheless, certain commands can be 
executed concurrently, for instance a SEARCH and several FETCHes can 
all be executed concurrently without a problem. With ESEARCH, 
multiple SEARCHes can be executed concurrently, of course, since it 
effectively adds tagged intermediates.

Moreover even a single-threaded server can, in some cases, combine 
the processing of a pipeline of commands, if this is beneficial, to 
avoid multiple scans through the mailbox.

> That stuff is all there in an attempt to placate those individuals 
> (not that it did...).  The only practical benefit was the limited 
> amount of pipelining that you can do in IMAP.

With current servers, yes.

Dave.

