52 lines
2.7 KiB
Plaintext
52 lines
2.7 KiB
Plaintext
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.
|
|
|