MBOX-Line: From witold.krecicki at firma.o2.pl  Mon Jun 14 13:56:29 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <alpine.OSX.2.00.1006141310330.662@hsinghsing.panda.com>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006141208460.662@hsinghsing.panda.com>
	<alpine.OSX.2.00.1006141310330.662@hsinghsing.panda.com>
Message-ID: <201006142256.29781.witold.krecicki@firma.o2.pl>

On Monday 14 of June 2010 22:43:21 Mark Crispin wrote:
> The operation of moving messages from source to destination pipelines two
> operations in one of two ways:
>  	[a] for each message:
>  		[1] insert in destination
>  		[2] remove from source
> or
>  	[b] [1] insert all in destination
>  	    [2] remove all from source
> 
> If [a][1] fails, then [a][2] is not executed for that iteration.  However,
> earlier iterations may have succeeded.  If [a][2] fails, then the result
> is a copy for that iteration, but earlier iterations may have moved.
> 
> If [b][1] fails, then [b][2] is not executed and the move operation fails.
> If [b][2] fails, then the result is a copy.
> 
> Implementations [a] and [b] both create, for the first time in IMAP, a
> "partial success" result.  The result from implementation [a] is far more
> complex and requires far more complex protocol
Bulls*it. 
COPY (in Maildir) can fail partially (not all messages copied). EXPUNGE can 
fail that way (not all messages expunged). It's all a matter of proper 
implementation to not get a chance of a partial failure.

> There's also the matter of whatever UIDPLUS results are returned.  Since
> MOVE expunges from the source, then UIDPLUS results are either dangling
> (like COPYUID, but referring to source UIDs that no longer exist) or
> unassociated (like APPENDUID).  This is unavoidable with any pipeline; but
> the status report gets particularly complex with implementation [a].
> 
> 
> The whole point to the proposed MOVE command is not syntactic sugar, but
> rather to pretend that this pipeline doesn't really exist.  Otherwise, it
> would just be a matter of fixing the RTTs of the pipeline by improving the
> pipelining mechanism, such as either a PIPELINE command or conditional
> execution.
You are forcing an opinion (on everyone) that this pipeline always exists AND 
that MOVE command cannot be made atomic, and it's certainly not true.

> Instead, what we have is a proposal that uniquely benefits certain
> databases (but NOT Maildir, since Maildir can use hard links) at the cost
> of substantial protocol complexity to support all the newly-created error
> cases.
You are creating those error cases,  based on Your interpretations. I'm able 
to think of an implementation (using Maildirs) in which MOVE command is either 
full success or full failure, and it's fully atomic. You can't.


-- 
Witold Kr?cicki

Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy, 
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513

