MBOX-Line: From mrc+imap at panda.com  Fri Jun 11 16:27:33 2010
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <30B328B7-4D1B-4C7E-96CA-E37F7919E2A6@iki.fi>
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>
Message-ID: <alpine.OSX.2.00.1006111603200.662@hsinghsing.panda.com>

On Fri, 11 Jun 2010, Timo Sirainen wrote:
> a COPY 1:100 elsewhere
> b IF-OK STORE 1:100 +flags \deleted
> c IF-OK EXPUNGE

Presumably, the real life-example would be:

 	a UID COPY 1:100 elsewhere
 	b IF-OK UID EXPUNGE 1:100

Other than the normal objections to new capabilities, there's nothing
really wrong with this idea.  It's a fairly obvious improvement to
existing IMAP pipelining.


On the other hand, I think that it would be better to have an explicit
pipeline facility in IMAP:

a PIPELINE 1:100 (b COPY $ elsewhere | c STORE $ +FLAGS \DELETED | EXPUNGE)

a UID PIPELINE 1:100 (b UID COPY $ elsewhere | c UID EXPUNGE $)

and deprecate the current way of pipelining.

PIPELINE would have the additional semantic (not in UID PIPELINE) that
untagged expunge events are prohibited until the pipeline completes.
Thus, an EXPUNGE in the middle of a pipeline would simply set an "expunge
when pipeline completes" flag and not actually expunge.

Note the $ to repeatedly apply the previous sequence set.

You could mix UID and non-UID (e.g., UID commands could happen in a
PIPELINE and non-UID commands could happen in UID PIPELINE) but normally
this would not be done.

Besides separating the portions of the pipeline, the | operator would be a
go/no-go point.  The result would either be:

 	a OK The pipeline worked

which indicates full success, or

 	a NO [TAG b] COPY failed

which would be the tag of the failed pipelined command.

Since there is (sub)tag error reporting, there is no need for the pipeline
to be atomic.

IF-OK is only needed in pipelining, so it's obviated here.  I guess that
we could have a second operator besides | if we really want a "don't care
if previous operation fails" functionality (but I don't see a need).


Another neat thing is that this completely eliminates the need for a MOVE
command.  A server that somehow can do internal move fast but not copy
could recognize the above two idioms and implement them as an internal
move.  Since it's a pipeline, it doesn't require atomicity, and it has an
error reporting mechanism.


Yet another neat thing is that this explicitly declares a pipeline, and we
can get rid of all the ridiculous client rules for pipelining that are in
IMAP now.


The question is: how many people would actually implement such a facility
if it were present?  The normal objections to new capabilities applies as
much to this idea.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

