[Imap-protocol] MOVE is a pipeline
Mark Crispin
mrc+imap at panda.com
Tue Jun 15 09:52:54 PDT 2010
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
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.
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
and
tag PIPELINE (UID COPY seq dest) (UID STORE $ +FLAGS.SILENT \Deleted) (UID EXPUNGE $)
instead of
tag UID MOVE seq dest
It's just syntactic sugar.
-- 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.
More information about the Imap-protocol
mailing list