On Thu, 26 May 2011, John Snow wrote:
> Philip Guenther wrote:
...
> > Right now, a client can parse a FETCH response at any time, inserting
> > it into its cache without having to consider any context of pending
> > commands. Indeed, the server can send FETCH responses at any time
> > (modulus TCP flow-control/deadlock concerns), and it's *required* to
> > do so for flag changes. Sometimes using the UID and sometimes using
> > msgno would make such unsolicited FETCH responses ambiguous.
>
> A UID fetch response could just as easily be handled at any time.
...
> why not this instead?
>
> Example: C: A999 UID FETCH 4827313:4828442 FLAGS
> S: * UID 4827313 FETCH (FLAGS (\Seen))
...
And unsolicited FETCH responses would have used which format? How would
the server have decided that?
IMAP message data/metadata processing is basically a cache-fill/coherency
algorithm: the client says "yo, server, please fill in my cache with at
least the following bits" and the server does so, while concurrently
keeping the cache coherent when metadata (flags) are changed by other
clients...and those are handled consistently, with a single response
format.
I take it you don't like that design.
Philip