129 lines
4.7 KiB
Plaintext
129 lines
4.7 KiB
Plaintext
MBOX-Line: From snowjn at aol.com Fri Jun 11 16:46:19 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.1006111603200.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> <30B328B7-4D1B-4C7E-96CA-E37F7919E2A6@iki.fi>
|
|
<alpine.OSX.2.00.1006111603200.662@hsinghsing.panda.com>
|
|
Message-ID: <4C12CACB.7030205@aol.com>
|
|
|
|
|
|
|
|
Mark Crispin wrote:
|
|
> On Fri, 11 Jun 2010, Timo Sirainen wrote:
|
|
>> a COPY 1:100 elsewhere
|
|
>> b IF-OK STORE 1:100 +flags \deleted
|
|
>> c IF-OK EXPUNGE
|
|
>
|
|
> Presumably, the real life-example would be:
|
|
>
|
|
> a UID COPY 1:100 elsewhere
|
|
> b IF-OK UID EXPUNGE 1:100
|
|
>
|
|
> Other than the normal objections to new capabilities, there's nothing
|
|
> really wrong with this idea. It's a fairly obvious improvement to
|
|
> existing IMAP pipelining.
|
|
>
|
|
>
|
|
> On the other hand, I think that it would be better to have an explicit
|
|
> pipeline facility in IMAP:
|
|
>
|
|
> a PIPELINE 1:100 (b COPY $ elsewhere | c STORE $ +FLAGS \DELETED |
|
|
> EXPUNGE)
|
|
>
|
|
> a UID PIPELINE 1:100 (b UID COPY $ elsewhere | c UID EXPUNGE $)
|
|
>
|
|
> and deprecate the current way of pipelining.
|
|
>
|
|
> PIPELINE would have the additional semantic (not in UID PIPELINE) that
|
|
> untagged expunge events are prohibited until the pipeline completes.
|
|
> Thus, an EXPUNGE in the middle of a pipeline would simply set an "expunge
|
|
> when pipeline completes" flag and not actually expunge.
|
|
>
|
|
> Note the $ to repeatedly apply the previous sequence set.
|
|
>
|
|
> You could mix UID and non-UID (e.g., UID commands could happen in a
|
|
> PIPELINE and non-UID commands could happen in UID PIPELINE) but normally
|
|
> this would not be done.
|
|
>
|
|
> Besides separating the portions of the pipeline, the | operator would
|
|
> be a
|
|
> go/no-go point. The result would either be:
|
|
>
|
|
> a OK The pipeline worked
|
|
>
|
|
> which indicates full success, or
|
|
>
|
|
> a NO [TAG b] COPY failed
|
|
>
|
|
> which would be the tag of the failed pipelined command.
|
|
>
|
|
> Since there is (sub)tag error reporting, there is no need for the
|
|
> pipeline
|
|
> to be atomic.
|
|
>
|
|
> IF-OK is only needed in pipelining, so it's obviated here. I guess that
|
|
> we could have a second operator besides | if we really want a "don't care
|
|
> if previous operation fails" functionality (but I don't see a need).
|
|
>
|
|
>
|
|
> Another neat thing is that this completely eliminates the need for a MOVE
|
|
> command. A server that somehow can do internal move fast but not copy
|
|
> could recognize the above two idioms and implement them as an internal
|
|
> move. Since it's a pipeline, it doesn't require atomicity, and it has an
|
|
> error reporting mechanism.
|
|
>
|
|
>
|
|
> Yet another neat thing is that this explicitly declares a pipeline,
|
|
> and we
|
|
> can get rid of all the ridiculous client rules for pipelining that are in
|
|
> IMAP now.
|
|
>
|
|
>
|
|
> The question is: how many people would actually implement such a facility
|
|
> if it were present? The normal objections to new capabilities applies as
|
|
> much to this idea.
|
|
>
|
|
|
|
I've never understood how pipelining commands is useful. If I were
|
|
writing a client, I would
|
|
want to know the outcome of each command before issuing the next. It
|
|
seems that this
|
|
proposal just makes things more complicated just to eliminate the need
|
|
for a move command.
|
|
|
|
The move command is an explicit indicator the the client intends for the
|
|
message to be somewhere
|
|
else. Why should I parse multiple commands to try and interpret the
|
|
client's intentions?
|
|
|
|
Move is just easier to understand. I assume that's why Unix has
|
|
commands for both copy and
|
|
move. You can cp a file to a new directory then delete the original, or
|
|
you could just mv it.
|
|
mv may do the copy and delete under the covers but, as a user, I don't
|
|
really care how it happens.
|
|
|
|
This same sort of optimization exists all through the IMAP protocol.
|
|
Why do we have the ability
|
|
to fetch anything less the the complete message? A client could fetch
|
|
the message and just throw out
|
|
the stuff it doesn't want. Instead, the client can ask for just what it
|
|
needs. That's an optimization.
|
|
|
|
snow.
|
|
|
|
> -- 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.
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100611/a892986a/attachment.html>
|