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>
