[Imap-protocol] MOVE is a pipeline

[John Snow]

Mark Crispin wrote:

> On Tue, 15 Jun 2010, Dan Karp wrote:

>> And you can probably nip a (misguided) MOVE.SILENT in the bud at this

>> stage.

>

> Like I am nipping misguided MOVE in the bud?  :p

>

> I don't think that it is ever safe to rely upon an attractive nuisance

> being nipped in the bud.  Historically, such reliance has never been

> well-founded.

>

>> Likewise, MOVEANDCLOSE doesn't have a real-world use case, as a move

>> isn't correlated with the end of a SELECT.  Quite the opposite, in fact.

>

> Not necessarily.  "Move all the junk to trash and then close" may be an

> operation that clients want to do.

>

> Move via a pipeline idiom, as opposed to a specific MOVE command, solves

> the problem.  The normal move is

>    pipeline COPY + STORE + EXPUNGE

> and the less chatty move is

>    pipeline COPY + STORE silent + EXPUNGE

> and the quiet move is

>    pipeline COPY + STORE silent + CLOSE

>

We agreed earlier that pipelining copy+store+expunge is a bad idea, 
because of
the potential data loss if the COPY failed.


> The pipeline does not create any new error states.  The error states are

> all those which must be handled anyway.

>

>> From the client perspective, the pipeline does not add new complexity 

>> over

> a MOVE command.  It is just syntactic sugar.

>

> The pipeline is more general.  Over time, perhaps, new idioms which the

> server can optimize may come to be.  That would be strictly within the

> server implementation (although perhaps published as "look at this neat

> trick we can do!"), with no need to change the protocol (and thus NO need

> to go through the process we are doing now).

>

> MOVE, on the other hand, is a one-shot that benefits some servers but not

> others, and may tempt a disastrously bad implementation.

>

> Even better, pipelining is something that we all agree we need in IMAP.

> I think that we all would like to see a better mechanism than what is

> there now.

Don't say ALL.  I never understood why it's useful.  Pipelining commands
removes the client's ability to deal with an error response between 
commands.

>

> I would love to abolish the rules in 5.5 and 7.4.1 in favor of a pipeline

> that blocks EXPUNGE while it is in progress plus a separate rule that

> external-caused untagged EXPUNGE events must be deferred until the end of

> a pipeline (or command in the case of a non-pipelined command).  I don't

> see how that can be done without a major revision of IMAP, but we can at

> least start the process and label the 5.5 and 7.4.1 rules as legacy.

>

> For the purposes of idioms that servers can optimize, a PIPELINE command

> would probably be better than IF-OK.  Just think of the approved syntax

> for the MOVE command as being:

>  tag PIPELINE (COPY seq dest) (STORE $ +FLAGS.SILENT \Deleted) (EXPUNGE)

> instead of

>  tag MOVE seq dest

The MOVE looks a lot simpler.

> and

>  tag PIPELINE (UID COPY seq dest) (UID STORE $ +FLAGS.SILENT \Deleted) 

> (UID EXPUNGE $)

> instead of

>  tag UID MOVE seq dest

Same here

The PIPELINE and IF-OK options are getting close to defining a scripting
language.  Are you planning to a an ELSE?

tag  COPY 1:100 saved
tag IF-OK STORE 1:100 +flags \deleted
tag ELSE STORE 1:100 +flags \flagged



>

> It's just syntactic sugar.

sweet!

>

> -- 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 at u.washington.edu

> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman2.u.washington.edu/pipermail/imap-protocol/attachments/20100615/9dcc3af5/attachment.html