MBOX-Line: From witold.krecicki at firma.o2.pl  Mon Jun 14 13:16:41 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.OSX.2.00.1006141208460.662@hsinghsing.panda.com>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006142108.34481.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006141208460.662@hsinghsing.panda.com>
Message-ID: <201006142216.41783.witold.krecicki@firma.o2.pl>

On Monday 14 of June 2010 21:52:24 Mark Crispin wrote:
> On Mon, 14 Jun 2010, Witold Kr?cicki wrote:
> >> The new message store that I am designing now is single instance.  It is
> >> targeted for CAstor where there is no filesystem at all; just pointers.
> > 
> > Then why not design it so that MOVE is possible and easy?
> 
> I could.
> 
> However, MOVE is pointless in that store.  I would have to think long and
> hard to justify the expense of the added work (which in this case is a
> simultanous commit of two indices with all-commit or none-commit).
> 
> None of our customers have asked us for MOVE.  The addition of the
> necessary code paths and error conditions increases the support costs.
Have you ever offered them MOVE? Or did you just replied that they're cocky and 
want to undo the 25-year history of IMAP?
 
> For the client, at best, it saves the client an RTT or two.  However, the
> complexity of new error states vastly overweighs the savings.  This thread
> already discussed alternatives by which we could do a pipeline with
> conditional execution of the UID EXPUNGE (thus having the advantage of
> MOVE without the complexity).
You're creating the complexity of MOVE at the every step of this discussion. 
For me it's a simple operation. And yes, I have thought it through. 

> To benefit a server, it must be BOTH:
> [1] technically impossible to copy a message on the mail store without
>      copying the message text.
> [2] possible to move the message without copying the message text.
> 
> Yet, it has already been shown that this is not the case for flat files
> nor for Maildir.
> 
> In the case of flat files, and Maildir with source and target on different
> filesystem, [1] is true and [2] is false.
> 
> In the case of Maildir with source and target on the same filesystem, [1]
> is demonstrably false.  It may be that some Maildir users don't want to
> deploy the solution for [1].  But that does not mean that we should make
> IMAP more complicated, especially since [2] isn't really true due to the
> added irreversible failure modes.
I wanted to comment 'IMAP more complicated' but I just won't...

> Thus, the server benefit, such as it is, is for some database type store
> which can not do a basic-level operation quickly but can do an extended
> operation quickly.
I know that in Your UW-IMAP-based universe copy is 'basic', move is 
'extended'. But it's not the general rule.
 
> In other words, for the benefit of a poorly-designed database, we are
> supposed to add substantial complexity to IMAP and break a guarantee that
> is a fundamental part of IMAP?!?
I don't want to break this guarantee, it's You who's stating that it's 
impossible to make MOVE atomic. I oppose every time.

-- 
Witold Kr?cicki

Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy, 
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513

