MBOX-Line: From stujenerin at aol.com  Tue Jun 15 05:10:20 2010
To: imap-protocol@u.washington.edu
From: Stu Brandt <stujenerin@aol.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <4C172E12.40600@gulbrandsen.priv.no>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>	<201006142330.15547.witold.krecicki@firma.o2.pl>	<alpine.OSX.2.00.1006141445490.662@hsinghsing.panda.com>	<201006150033.17670.witold.krecicki@firma.o2.pl>
	<4C172E12.40600@gulbrandsen.priv.no>
Message-ID: <4C176DAC.4050005@aol.com>

Mark Crispin wrote:
> A user doesn't give a damn whether the "move" button does one IMAP 
> command
> or 69 IMAP commands.
They *absolutely* do when it comes to failure scenarios of the current 3 
command sequence that leaves messages laying around in both folders. And 
while it would be easy to find fault with client developers whose 
rollforward/rollback handling during failure might be lacking, I frankly 
think some of the fault lies with a protocol that shifts the burden of 
MOVE atomicity back onto the Client rather than the Store.
>
> The only people who care are server authors, who want to kludge around 
> the
> deficiencies of their message stores, and perhaps client authors who want
> to save an RTT.
>
> There is no reason, other than a careless mail store implementation, that
> a MOVE should be faster than a COPY.
At the risk of restating facts already presented by Arnt Gulbrandsen and 
Dan Karp, discussion of MOVE vs. COPY is a distraction. We've 
established that COPY/EXPUNGE can not be pipelined because of the 
possibility of failure of COPY. And Arnt clearly demonstrated that MOVE 
will almost assuredly be faster than the current 3 command sequence. 
Throw in the fact that MOVE actually *could* be atomic in such stores, 
and it's clear that a MOVE extension would be a nice win for Mail Store 
performance, client developers, and ultimately users.

If you look at the UIs from companies that have spent millions of 
dollars (possibly tens/hundreds of millions) on researching exactly what 
users want in a mail client -- Yahoo, AOL, Apple, etc -- many of those 
UIs don't even offer COPY as a user facing option in some of their 
products. I think it's long past due that Mail Store developers 
acknowledge MOVE as a primary use case and raise the bar to actually 
design systems that make it a first-class atomic operation.

Barring that, however, I still think there's a middle ground whereby a 
MOVE command could allow clients to tap into the atomic nature of some 
stores' handling while also providing enough flexibility in the response 
for non-atomic Stores to reflect accurate message state back to clients 
in the case of failure.

