69 lines
2.5 KiB
Plaintext
69 lines
2.5 KiB
Plaintext
MBOX-Line: From tss at iki.fi Thu May 3 11:00:35 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:48 2018
|
|
Subject: [Imap-protocol] Concurrent flag changes
|
|
In-Reply-To: <4FA270A0.3040003@gulbrandsen.priv.no>
|
|
References: <14DB8F84-E3D5-426A-BBF6-5B4746B6E3DF@iki.fi>
|
|
<4FA270A0.3040003@gulbrandsen.priv.no>
|
|
Message-ID: <A2C8BAB1-76FF-4468-A7B6-45FEE67D8FBA@iki.fi>
|
|
|
|
On 3.5.2012, at 14.48, Arnt Gulbrandsen wrote:
|
|
|
|
> Timo wrote:
|
|
>> Clients C1 and C2 send:
|
|
>
|
|
> It can also be connections C1 and C2 by the same client. If it is, C1 is
|
|
> perfectly aware of what you told C2, and Dovecot is right today and
|
|
> would be broken by your suggested change.
|
|
|
|
Right, so I won't change the normal client-visible behavior at least. I was only thinking about that while writing the mail, because I thought I'd try to make the question more generic. :)
|
|
|
|
Another try at what I'm really after:
|
|
|
|
You want to sync two IMAP servers periodically, but not continuously. For an extreme example lets say you have 1) your real always-connected IMAP server, which you sometimes use via webmail and 2) another IMAP server on your laptop, which you carry around and isn't always connected. It's possible that you do changes in both of these servers while they are unsynced.
|
|
|
|
Or a similar issue could happen with a shared mailbox in a multi-master type of setup during a split brain.
|
|
|
|
So you have clients that issue STORE commands to the same mail in both servers, and you need to sync them together. Both servers keep a log of what STORE commands the clients have sent, so they can intelligently merge the changes by reading the logs.
|
|
|
|
So the obvious merges for a keyword called "k" are:
|
|
|
|
S1: +FLAGS k
|
|
S2: +FLAGS k
|
|
result: k set
|
|
|
|
S1: -FLAGS k
|
|
S2: -FLAGS k
|
|
result: k unset
|
|
|
|
S1: +FLAGS k
|
|
S2: <no change>
|
|
result: k set
|
|
|
|
S1: -FLAGS k
|
|
S2: <no change>
|
|
result: k unset
|
|
|
|
Then there's a real conflict:
|
|
|
|
S1: +FLAGS k
|
|
S2: -FLAGS k
|
|
result: use whichever server changed it later
|
|
|
|
But the one that I'm not entirely sure about:
|
|
|
|
S1: FLAGS k
|
|
S2: +FLAGS k2
|
|
|
|
If S1 is done before S2, result: k k2
|
|
If S1 is done after S2, result: k? Or perhaps still "k k2", because S1 definitely didn't know that S2 had added a flag.
|
|
|
|
Then there's of course what happens with CONDSTORE. If the order of operations is:
|
|
|
|
S1: +FLAGS k
|
|
S2: +FLAGS k2
|
|
S1: (UNCHANGEDSINCE ..) FLAGS (k3)
|
|
|
|
Because the sync happens only after the conditional FLAGS has already succeeded and returned to client, I think the only reasonable result for this is "k2 k3".
|