MBOX-Line: From mrc+imap at panda.com  Mon Jun 14 12:52:24 2010
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <201006142108.34481.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<alpine.OSX.1.10.1006140942380.2640@mbp.lyndon.corp.flock.com>
	<alpine.OSX.2.00.1006141014400.662@hsinghsing.panda.com>
	<201006142108.34481.witold.krecicki@firma.o2.pl>
Message-ID: <alpine.OSX.2.00.1006141208460.662@hsinghsing.panda.com>

On Mon, 14 Jun 2010, Witold Kr?cicki wrote:
>> The new message store that I am designing now is single instance.  It is
>> targeted for CAstor where there is no filesystem at all; just pointers.
> Then why not design it so that MOVE is possible and easy?

I could.

However, MOVE is pointless in that store.  I would have to think long and
hard to justify the expense of the added work (which in this case is a
simultanous commit of two indices with all-commit or none-commit).

None of our customers have asked us for MOVE.  The addition of the
necessary code paths and error conditions increases the support costs.

For the client, at best, it saves the client an RTT or two.  However, the
complexity of new error states vastly overweighs the savings.  This thread
already discussed alternatives by which we could do a pipeline with
conditional execution of the UID EXPUNGE (thus having the advantage of
MOVE without the complexity).

To benefit a server, it must be BOTH:
[1] technically impossible to copy a message on the mail store without
     copying the message text.
[2] possible to move the message without copying the message text.

Yet, it has already been shown that this is not the case for flat files
nor for Maildir.

In the case of flat files, and Maildir with source and target on different
filesystem, [1] is true and [2] is false.

In the case of Maildir with source and target on the same filesystem, [1]
is demonstrably false.  It may be that some Maildir users don't want to
deploy the solution for [1].  But that does not mean that we should make
IMAP more complicated, especially since [2] isn't really true due to the
added irreversible failure modes.

Thus, the server benefit, such as it is, is for some database type store
which can not do a basic-level operation quickly but can do an extended
operation quickly.

In other words, for the benefit of a poorly-designed database, we are
supposed to add substantial complexity to IMAP and break a guarantee that
is a fundamental part of IMAP?!?

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