MBOX-Line: From witold.krecicki at firma.o2.pl  Fri Jun 11 14:52:05 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:43 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.OSX.2.00.1006111214020.662@hsinghsing.panda.com>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006112113.56572.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006111214020.662@hsinghsing.panda.com>
Message-ID: <201006112352.05642.witold.krecicki@firma.o2.pl>

I don't want to address all the points in Your mail right now, so I'll address 
just the most important to me:

On Friday 11 of June 2010 23:17:56 Mark Crispin wrote:
> On Fri, 11 Jun 2010, Witold Kr?cicki wrote:
> >> MOVE doesn't solve those problems in maildir; it makes them worse.  MOVE
> >> doesn't solve those problems in other formats either.
> > 
> > No, MOVE keeps the problems in maildirs at the same level. It does not
> > make them worse.
> 
> Yes, because MOVE introduces requirements and semantics that currently DO
> NOT EXIST in IMAP.
> 
> By its definition, MOVE must fufill the requirement of removing from the
> source.  There is no way that this can not be done; otherwise it would be
> a COPY and not a MOVE.
> 
> IMAP has no guaranteed means of removing a message.  Study the semantics
> of STORE and EXPUNGE carefully.  MOVE, on the other hand, requires that
> guarantee; and does not have the semantics of STORE and EXPUNGE.
<quote>
The EXPUNGE command permanently removes all messages that have the
      \Deleted flag set from the currently selected mailbox.  Before
      returning an OK to the client, an untagged EXPUNGE response is
      sent for each message that is removed.
</quote>
I really don't get the point, please be more specific.


> >> MOVE provides no real benefit to such stores; yet those stores are the
> >> only ones that can actually implement it properly.
> > 
> > Database-backed stores can implement it properly and can have performance
> > boost.
> 
> So, you postulate a database which is designed to have a performance boost
> in the case of this extension, yet can not implement the base
> specification without a performance cost.
COPY is by definition a slow operation. Using hardlinks etc. is a performance 
hack, not a normal method.

> > But
> > read few lines above - I have written client case (specifically on weak
> > connection clients such as GPRS/EDGE).
> 
> I've used such environments (and far worse) for well over 15 years.
> 
> We do not move forward by adding new capabilities to solve yesterday's
> problems tomorrow.
> 
> 2G (and 1G before that) radio is yesterday's problem.  And it wasn't that
> much of a problem.  The extra RTTs can be eliminated by pipelining, and it
> is extremely rare that you have a sparse enough sequence that the byte
> count becomes significant.
Pipelining that can cause (copy/store/expunge with failed copy) permanent loss 
of data if COPY fails. 
So we have a MOVE command that can be non-atomic in some rare, extreme (FS 
failure) cases and pipelining copy/store/expunge with the risk of losing data 
'with respect to the protocol and with full atomicity'. What do you think is 
better from client point of view?

> >> If AOL uses a database that permits that kind of operation, then there
> >> is no reason why COPY can not also work that way.
> > 
> > In this example COPY would create a need to insert new records, MOVE is
> > just update. How could COPY work that way?
> 
> If MOVE can be done atomically by an update, there is no reason why COPY
> can not be done that way too.
COPY creates NEW entity, MOVE only changes properties of an EXISTING entity. 

> >> This is an "attractive nuisance".  It's one of those ideas that sounds
> >> really good on paper until you study the unintended consequences.
> > 
> > What consequences?
> 
> A facility that is unimplementable with some stores, some of which
> (notably Maildir) appear to be implementable albeit by a dangerous
> implementation that can (and will!) cause indeterminate results to
> clients.
If COPY is implementable then MOVE is implementable. period.

In Maildir it can (and will!) cause indeterminate results to client only in 
case of catastrophic failure. So will COPY in case of catastrophic failure.
 
> A facility that, on the stores where it is implementable, provides no
> compelling advantage.  You have to presuppose a store that is designed so
> that COPY must be slow and MOVE must not be yet is atomic.
read above.
 
> IMAP has generally not added features whose sole purpose is to provide
> support for a particular type of store.  Far more common is that a
> particular type of store has vetoed a proposed addition.
MOVE creates advantage for any kind of single-labeled flat store.

> > And that sounds like total inability to listen to your counterpart on
> > Your part.
> 
> This is not the first time this discussion has taken place.
> 
> Every few years, a newcomer comes along and says "I have this simple
> solution that you all should adopt."  Then more experienced people try to
> explain the complexities of the situation.
Currently You are the only one more experienced that is trying to explain the 
complexities of the situation. Most of the people here (I'm silently assuming 
that they are not all newcomers) agreed that it is in fact a needed feature.

-- 
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

