Re: [Imap-protocol] Gmail flags issue, timing-sensitive

( below )

2015-03-25 23:56 GMT+03:00 Michael M Slusarz <[email protected]>:

> Quoting Arnt Gulbrandsen <[email protected]>:
>
>  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.
>

RFC 4551 says:

An IMAP server that supports this extension MUST associate a positive
   unsigned 64-bit value called a modification sequence (mod-sequence)
   with every IMAP message.  This is an opaque value updated by the
   server whenever a metadata item is modified.  The server MUST
   guarantee that each STORE command performed on the same mailbox
   (including simultaneous stores to different metadata items from
   different connections) will get a different mod-sequence value.


Since a MODSEQ is associated with each message, there is no valid way (that
I can see) for a message to have different flags and identical MODSEQ value.


> (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.)
>

The most recent one was in the context of a STORE *and* it only works that
way with regards to \Answered and $Forwarded.

For \Seen (original example), it works the other way, new state first, old
state next.

Far too many "special cases" to view it as harmless, cute, and intended
implementation details.


>
> 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.


That's fine if you use CONDSTORE and have MODSEQ values to pick the most
current one, but if you don't... From my original message:

14:39:06.189: [IMAP.5455] Sending: kman10 UID STORE 86 +FLAGS (\Seen)
{{{---}}}
14:39:06.490: [IMAP_RAW.5455] Data is <84>:
14:39:06.490: * 58 FETCH (FLAGS (\Seen) UID 86)
14:39:06.490: * 58 FETCH (UID 86 FLAGS ())
14:39:06.490: kman10 OK Success

No MODSEQ values here to choose one or the other (SELECT didn't have
CONDSTORE, turned off while investigating).

In web mail and on later syncs, the message is \Seen, so the *first*
response line is correct, and the *second* one is not, and by the time you
get to "command fully completed", you've got wrong state.



> 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.


Agree, but none of my examples had a sudden connection loss.


> 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.
>

I never said anything updating the database and the UI on every line
received from an IMAP server :)

But I'll take your statement further -- for me personally, IMAP's view of
clients as state machines ready for pretty much any data at pretty much any
time -- seems strange, impractical, and I can't quite wrap my brain around
it. Maybe it's because I never learned LISP.


>
> 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.


But sometimes one gets "reminders" that software is not made of strict
semantics, it's made of implementation details, and sometimes those details
misbehave.

I shall crawl back into my cave too now and keep my fingers crossed for the
Gmail IMAP team to (eventually) fix what I've reported :)

-- K

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol