MBOX-Line: From imap-protocol at lists.grepular.com  Sun Aug 29 02:39:02 2010
To: imap-protocol@u.washington.edu
From: Mike Cardwell <imap-protocol@lists.grepular.com>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] "Multiple Commands in Progress" real life support
	and ambiguity questions
Message-ID: <4C7A2AB6.6070405@lists.grepular.com>

I'm currently implementing an IMAP4rev1 server and am a little stuck on
section 5.5 of rfc3501:

http://tools.ietf.org/html/rfc3501#section-5.5

I understand that the client can send additional commands before
receiving the command completion result, and that the server can process
and respond to those commands in any order (subject to ambiguity
considerations)

In reality, do any servers actually do that though, or do they all tend
to run the commands synchronously and in order? Also, do any clients
take advantage of this ability or do they tend to use multiple
connections instead if they want to run multiple commands asynchronously?

I'm trying to gauge whether or not it would be worth the extra work and
complexity to make the server run multiple commands at the same time on
a single connection. Also, are there any clients that are known to break
when receiving server responses "out of order" ?

Also, is there an exhaustive set of ambiguity rules listed anywhere
which need to be looked out for when executing multiple commands at the
same time? The RFC suggests there are lots of cases, then provides only
a few examples. I find it confusing how the examples are written as
well. Eg, the following is apparently "invalid" :

FETCH + NOOP + STORE

What does that mean in human readable terms? If the examples consisted
of two commands, then I would assume that meant command 2 has to wait
for command 1 to finish before starting, but most of the examples
consist of 3 or more commands..?

-- 
Mike Cardwell - Perl/Java/Web developer, Linux admin, Email admin
Read my tech Blog -              https://secure.grepular.com/
Follow me on Twitter -           http://twitter.com/mickeyc
Hire me - http://cardwellit.com/ http://uk.linkedin.com/in/mikecardwell

