79 lines
3.3 KiB
Plaintext
79 lines
3.3 KiB
Plaintext
MBOX-Line: From slusarz at curecanti.org Wed Mar 25 13:56:27 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Michael M Slusarz <slusarz@curecanti.org>
|
|
Date: Fri Jun 8 12:34:54 2018
|
|
Subject: [Imap-protocol] Gmail flags issue, timing-sensitive
|
|
In-Reply-To: <64e2246f-9d64-40bc-b373-ec6a45f6acfb@gulbrandsen.priv.no>
|
|
References: <CAN7dqjCYRb2sbOZS49hiqgrSsfKFTzyT-b5fKHm0U4mBGvDRzA@mail.gmail.com>
|
|
<CABa8R6t01i4CMumftDbTdY_xC7WYWLCmh7__Qg+zrsw8dZxHwA@mail.gmail.com>
|
|
<CAN7dqjAxtu=k65vF-gshYYiEdMVeJ_j_ZruB2RLQRHTxouRckA@mail.gmail.com>
|
|
<CAN7dqjBcK_UZ1uYcT-G=a7N7W=g_JoAXf=kHSL6sz9EmMtc-9g@mail.gmail.com>
|
|
<20150325132119.Horde.H9br3-icKPf32c5xmMNhdfM@bigworm.curecanti.org>
|
|
<64e2246f-9d64-40bc-b373-ec6a45f6acfb@gulbrandsen.priv.no>
|
|
Message-ID: <20150325145627.Horde.BnbIyKq__wNeZ750DElb2MD@bigworm.curecanti.org>
|
|
|
|
Quoting Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>:
|
|
|
|
> Michael M Slusarz writes:
|
|
>> This is inefficient. But it is perfectly acceptable IMAP.
|
|
>
|
|
> It's not acceptable: the modseq should change whenever the flags do.
|
|
|
|
It sounds like people are agreeing that:
|
|
|
|
a001 SOME COMMAND
|
|
* 1 FETCH (FLAGS (\Foo) MODSEQ (2) UID 1)
|
|
[snapshot 1]
|
|
* 1 FETCH (FLAGS (\Foo \Bar) MODSEQ (2) UID 1)
|
|
[snapshot 2]
|
|
a001 OK
|
|
[snapshot 3]
|
|
|
|
...means that the flags on message 1 supposedly "changed" twice. In
|
|
other words, people are updating internal modseq caches at [snapshot
|
|
1] and [snapshot 2].
|
|
|
|
I don't see it that way. I view this series of commands as telling me
|
|
"what is the mailbox state as of snapshot 3". I don't care about
|
|
snapshot 1 or snapshot 2. I only care that at the end of the command,
|
|
I look at this and say that MODSEQ 2 is associated with flags (\Foo
|
|
\Bar) since that is what the server reported. I don't care about
|
|
intermediate transport steps the server took to inform the client of
|
|
this; I only care about the final state.
|
|
|
|
(I would agree that the Gmail example provided is incorrect *if* the
|
|
FETCH responses were received as unsolicited responses in an IDLE
|
|
command. But that wasn't the context of the example provided.)
|
|
|
|
For example, I have definitely seen this before:
|
|
|
|
a002 UID STORE [...]
|
|
* 1 FETCH (MODSEQ (2))
|
|
* 1 FETCH (FLAGS (\Foo \Bar) MODSEQ (2) UID 1)
|
|
a002 OK
|
|
|
|
A local synchronized mailbox would be in an invalid state if you
|
|
updated it after the first FETCH. This response may be broken from a
|
|
protocol standpoint, but it happens and I want/have to be able to deal
|
|
with it.
|
|
|
|
I think my disconnect with the majority is looking at client commands
|
|
from a transactional perspective rather than each individual FETCH
|
|
component. I'm only interested in committing the changes if the client
|
|
command is fully completed. If an IMAP session terminates before the
|
|
command is complete, I would much rather toss that data to be on the
|
|
safe side, especially since there is no guarantee that the cached data
|
|
is correct when dealing with servers that may not be 100% protocol
|
|
correct. Not to mention there can be horrible performance issues with
|
|
a non-transactional approach, depending on the number of FETCH
|
|
responses involved and how the backend client cache storage is
|
|
configured - e.g. if that cache storage is not local.
|
|
|
|
So just me again confusing strict semantics with implementation
|
|
details. I shall crawl back into the hole from whence I came and not
|
|
bother this thread any more.
|
|
|
|
michael
|
|
|
|
|