MBOX-Line: From tss at iki.fi  Fri Jun 11 16:56:01 2010
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.OSX.2.00.1006111603200.662@hsinghsing.panda.com>
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>
	<alpine.OSX.2.00.1006111603200.662@hsinghsing.panda.com>
Message-ID: <493C7101-AC65-41BF-B222-E57A150BABB7@iki.fi>

On 12.6.2010, at 0.27, Mark Crispin wrote:

> 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.

1) Why the messageset parameter? Seems unnecessary to me (along with UID PIPELINE command).

Also it would be possible to avoid adding | to ATOM-SPECIALS by just using more parenthesis:

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

> Note the $ to repeatedly apply the previous sequence set.

This might conflict with SEARCHRES extension. Or maybe it could just "enhance" it.

> 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.

That would be a good idea, yes.

> 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.

A simple IF-OK would be much easier for everyone to initially implement than PIPELINE, but maybe PIPELINE wouldn't be too difficult either..
