MBOX-Line: From snowjn at aol.com  Thu May 26 17:58:49 2011
To: imap-protocol@u.washington.edu
From: John Snow <snowjn@aol.com>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] History question.
In-Reply-To: <alpine.BSO.2.00.1105261346420.31737@morgaine.smi.sendmail.com>
References: <4DDEA412.6030305@aol.com>
	<alpine.BSO.2.00.1105261253510.31737@morgaine.smi.sendmail.com>
	<4DDEB7EB.2090508@aol.com>
	<alpine.BSO.2.00.1105261346420.31737@morgaine.smi.sendmail.com>
Message-ID: <4DDEF749.3030400@aol.com>



Philip Guenther wrote:
> 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
>   
Whether I like it or not doesn't really matter.  My problem was 
understanding the need.

I think I got it now.  The problem is that's there's 2 ways to identify 
a message.  The absolute
UID and the relative MSN.  I was thinking only the UID was really 
needed.  But, that doesn't
allow for a client to fetch only predetermined number of messages.  
Sure, you could fetch a
range of UIDs, but there's no way to know how many and what end of the 
mailbox they
might represent.  So you need the MSN to fetch the user desired 
messages, otherwise you'd
have fetch all the messages just to find the ones you want.  That would 
indeed suck.  Since
you need both, and the client and server must be in sync, it must be 
returned in the untagged
response.  To be consistent, it seems that the UID should be returned on 
all fetch responses.
Oh well...

Thanks for the help.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20110526/90bbcad9/attachment.html>
