68 lines
3.1 KiB
Plaintext
68 lines
3.1 KiB
Plaintext
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
|
|
|