MBOX-Line: From witold.krecicki at firma.o2.pl  Fri Jun 11 14:13:11 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: <201006110854.37969.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
Message-ID: <201006112313.11799.witold.krecicki@firma.o2.pl>

Ok, to sum up the discussion after one day:

1. MOVE does not guarantee atomicity on some stores, but so does COPY. There 
are stores on which atomicity of MOVE is guaranteed (most of those on which 
COPY atomicity is also guaranteed) 

2. MOVE does not improve speed on some stores, but will never be slower than 
the usual cp/st/ex routine. It can improve speed on some specific, database-
backed stores

3. Pipelining of copy/store/expunge sequence seems like a good idea server-
side, but can be disastrous for client if the 'copy' fails (messages are lost 
permanently), move is an all-or-nothing (atomic if there is no 
filesystem/disk/etc. catastrophe on server side) command.

4. MOVE allows users to move messages even if they are close to their quota 
limits, which is (formally and often practically) impossible with regular 
copy/store/expunge sequence.

5. Move operation is already being implemented as an user extension (eg. XAOL-
MOVE) in both servers (AOL IMAP server) and clients (Thunderbird)

Revised version of draft can be found 
http://www.ietf.org/id/draft-krecicki-imap-move-01.txt 
here. Mostly grammar + some clarifications about atomicity.


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

