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

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.

(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

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