47 lines
2.1 KiB
Plaintext
47 lines
2.1 KiB
Plaintext
MBOX-Line: From snowjn at aol.com Fri Jun 11 12:49:12 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: John Snow <snowjn@aol.com>
|
|
Date: Fri Jun 8 12:34:43 2018
|
|
Subject: [Imap-protocol] IMAP MOVE extension
|
|
In-Reply-To: <alpine.OSX.2.00.1006111006350.662@hsinghsing.panda.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>
|
|
<alpine.OSX.2.00.1006111006350.662@hsinghsing.panda.com>
|
|
Message-ID: <4C129338.9030706@aol.com>
|
|
|
|
I'm sure I must be missing something, but how is pipelining a
|
|
COPY+STORE+EXPUNGE a valid non-waiting command sequence?
|
|
|
|
If the server has a problem and fails the COPY then successfully
|
|
processes the STORE and EXPUNGE commands, don't you end up
|
|
in a state where the messages are gone?
|
|
|
|
|
|
|
|
>
|
|
> Pipelining eliminates this, except perhaps for a protocol link over a
|
|
> 300bps modem where the extra chattiness might matter.
|
|
>
|
|
>
|
|
>> 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.
|
|
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100611/6b874858/attachment.html>
|