MBOX-Line: From snowjn at aol.com  Tue Jun 15 10:31:14 2010
To: imap-protocol@u.washington.edu
From: John Snow <snowjn@aol.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <alpine.OSX.2.00.1006150928190.662@hsinghsing.panda.com>
References: <306561054.4215.1276619210367.JavaMail.root@dogfood.zimbra.com>
	<alpine.OSX.2.00.1006150928190.662@hsinghsing.panda.com>
Message-ID: <4C17B8E2.8050602@aol.com>

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@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/20100615/9dcc3af5/attachment.html>
