[Imap-protocol] Concurrent flag changes
tss at iki.fi
Thu May 3 14:17:02 PDT 2012
On 4.5.2012, at 0.02, Bron Gondwana wrote:
> On Thu, May 03, 2012 at 09:00:35PM +0300, Timo Sirainen wrote:
>> 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.
> I've been thinking about how to handle that case a bit too, and my
> eventual position is "all keywords start unset, so in the event of
> a conflict, the act of setting the keyword wins". I.e., the result
> should be 'k k2' if you can't resolve timestamps to be certain what
> what was intended.
For the first +FLAGS vs. -FLAGS I think that's good. I'm actually going to use modseqs since adding timestamps just for this is a bit too much of a waste of space (unless there's some other reason in future that I want to add real timestamps).
But for the latter FLAGS vs. +FLAGS I'm not sure if timestamps matter at all. Assuming S1 didn't already have k2 keyword set, the "FLAGS k" change didn't explicitly tell server to remove k2. The client most likely didn't have any idea that another client had already set k2 elsewhere. So even if the syncing knows that "+FLAGS k2" was done before "FLAGS k", I'm thinking it shouldn't remove k2. So in my internal logs I'd change "FLAGS" to "-FLAGS <list of unwanted keywords>" followed by "+FLAGS <list of wanted keywords>". So in the "FLAGS k" case it might get translated to e.g. "-FLAGS k3 k6" and "+FLAGS k", which wouldn't affect "k2" at all.
More information about the Imap-protocol