44 lines
1.8 KiB
Plaintext
44 lines
1.8 KiB
Plaintext
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
|
|
|