MBOX-Line: From guenther+imap at sendmail.com  Thu May 26 14:00:15 2011
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] History question.
In-Reply-To: <4DDEB7EB.2090508@aol.com>
References: <4DDEA412.6030305@aol.com>
	<alpine.BSO.2.00.1105261253510.31737@morgaine.smi.sendmail.com>
	<4DDEB7EB.2090508@aol.com>
Message-ID: <alpine.BSO.2.00.1105261346420.31737@morgaine.smi.sendmail.com>

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

