78 lines
2.9 KiB
Plaintext
78 lines
2.9 KiB
Plaintext
MBOX-Line: From witold.krecicki at firma.o2.pl Tue Jun 15 15:38:34 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] MOVE is a pipeline
|
|
In-Reply-To: <1276626345.2916.50.camel@kurkku.sapo.corppt.com>
|
|
References: <1372616189.4386.1276624386644.JavaMail.root@dogfood.zimbra.com>
|
|
<1276626345.2916.50.camel@kurkku.sapo.corppt.com>
|
|
Message-ID: <201006160038.34411.witold.krecicki@firma.o2.pl>
|
|
|
|
On Tuesday 15 of June 2010 20:25:45 Timo Sirainen wrote:
|
|
> On Tue, 2010-06-15 at 10:53 -0700, Dan Karp wrote:
|
|
> > > Oh, now I started also thinking about NOTIFY+QRESYNC combination where
|
|
> > > you can tell it to send VANISHED replies at any time. If MOVE is
|
|
> > > sending EXPUNGE/VANISHED replies and if client cares about which ones
|
|
> > > of those were from MOVE, it couldn't really know since a VANISHED reply
|
|
> > > might have been sent to client just before the server received MOVE
|
|
> > > command.
|
|
> >
|
|
> > Would it be unreasonable to state that the only untagged EXPUNGE
|
|
> > responses from a MOVE command may be those directly resulting from
|
|
> > the MOVE? (UID MOVE, like UID FETCH, would have no such constraints.)
|
|
>
|
|
> But that's what I was trying to explain above that it doesn't
|
|
> necessarily work when enough extensions are being used:
|
|
>
|
|
> 1. Client 1 enables QRESYNC, so it gets VANISHED (uidset) replies
|
|
> instead of EXPUNGEs.
|
|
>
|
|
> 2. Client 1 enables NOTIFY extension and tells server that it can handle
|
|
> any untagged replies at any time (basically enables IDLE without the
|
|
> IDLE command being running).
|
|
>
|
|
> 3. Client 2 EXPUNGEs UID 123.
|
|
>
|
|
> 4. Client 1 sends UID MOVE 1 command.
|
|
>
|
|
> 5. Server sends VANISHED update to client 1.
|
|
>
|
|
> 6. Server starts processing UID MOVE command.
|
|
>
|
|
> The result looks like:
|
|
>
|
|
> C: a UID MOVE 1 elsewhere
|
|
> S: * VANISHED 123
|
|
> S: * VANISHED 1
|
|
> S: a OK [UIDMOVE 1] Moved
|
|
>
|
|
> I don't know if that's a big problem, but "EXPUNGEs can't be sent during
|
|
> MOVE" is incompatible with QRESYNC+NOTIFY.
|
|
It's a pity that untagged EXPUNGE/VANISHED/etc. cannot contain response codes,
|
|
it'd make it so easy...
|
|
But maybe the solution that is used in SELECT
|
|
The result of previous situation:
|
|
|
|
C: a UID MOVE 1 elsewhere
|
|
S: * VANISHED 123
|
|
S: * OK [UIDMOVE 1] Moved / * OK [MOVE] Moved in case of lack of UIDPLUS
|
|
extension
|
|
S: * VANISHED 1
|
|
S: a OK Moved
|
|
|
|
of course untagged OK [MOVE]/ OK [UIDMOVE] must be directly preceeding proper
|
|
VANISHED/EXPUNGE untagged response, or it could state that the next N coming
|
|
VANISHED/EXPUNGE responses are the result of previous MOVE.
|
|
|
|
That also solves problem with UIDMOVE response that is sent after the message
|
|
could be removed from client local indices by EXPUNGE responses.
|
|
|
|
|
|
--
|
|
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
|
|
|