MBOX-Line: From mrc+imap at panda.com  Fri Jun 11 10:25:14 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: <1276274718.22134.138.camel@kurkku.sapo.corppt.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>
Message-ID: <alpine.OSX.2.00.1006111006350.662@hsinghsing.panda.com>

On Fri, 11 Jun 2010, Timo Sirainen wrote:
>> If MOVE is not atomic, then what is its point?
> 1) Allowing user to move messages between mailboxes in situations where
> a COPY would bring user over quota.

That presupposes a mail store in which COPY would bring the user over
quota.  As with a database, there's no reason why that should be the case
with a maildir type store.  A maildir store can use hardlink to implement
COPY.

> 2) Simplify the operation for clients, also drop one round trip wait. I
> guess this mainly would benefit some custom webmail developers that
> develop against a specific server..

Pipelining eliminates this, except perhaps for a protocol link over a
300bps modem where the extra chattiness might matter.

> 3) Possibly improve performance with some server implementations.

Most of this is with the idea of "just use rename", which breaks
atomicity.

> Are these good enough reasons for the MOVE command? I don't know. Maybe
> 1) is helpful sometimes.

I agree that (1) is the attraction.  But, once again, I don't see how MOVE
can solve the problem, simply because the stores which have the problem
can't do MOVE.

> It would behave essentially the same as COPY+STORE+EXPUNGE, except the
> STORE part could be optimized away:
> 1. The COPY part either atomically succeeds or fails.
> 2. Now the messages are visible in both mailboxes
> 3. Server starts expunging the moved messages.

Then you don't have a MOVE command.  You have a protocol macro that looks
like a command but actually is three separate commands.  And the client
has to be aware of the split in the macro since failures can happen at
each stage.

The complexities of this make the late unlamented VIEW proposal look
simple by comparison.

> After the copying is successful, the only problem that can happen is if
> expunging messages somehow fails, or if the server crashes. The same
> problems exist with COPY already, there are short time windows when if
> Dovecot crashes it has succeeded in only partially copying messages.

My mix format doesn't have those windows.

Flat file formats are screwed in crashes, but don't have the windows for
error recovery.

> Atomic MOVE sounds nice, but what benefit does it really have? I doubt
> clients or users care that much.

I agree.

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

