Re: New draft: SEARCH return options

[Alexey Melnikov <[e-mail]>]

Philip Guenther wrote:

>[Not sent to lemonade.  Do we really need to carry on this discussion in
>both places?]
>  
>
Thanks!

>Cyrus Daboo <[e-mail]> writes:
>...
>  
>
>>There is also an interesting possibility of tying the two together via the 
>>ID return option I proposed. For example:
>>
>>C: a SEARCH RETURN (ID 1 ALL) UNSEEN
>>    
>>
>...
>  
>
>>C: FETCH $[1] (UID INTERNALDATE FLAGS RFC822.HEADER)
>>    
>>
>...
>  
>
>>The fetch commands act on the result of the different searches, referenced 
>>by the ID option value. This means that a client could use multiple search 
>>result sets simultaneously, as opposed to in series, as they would have to 
>>right now.
>>    
>>
>
>The '$' token in draft-melnikov-imap-search-res-01.txt references the
>last SEARCH result, so it only requires the server to remember the one
>such result.
>
Yes, that was the original intent. Even if the client has specified 
"RETURN (COUNT)", the "$" construct still references the set of found 
messages.

>  If multiple search responses need to be remembered then
>some limit needs to be placed on how many a client can expect a server
>to remember and perhaps the client will need some way of controlling
>their lifetime.
>  
>
Yes.
I was thinking about remembering multiple SEARCH results, but this might 
overcomplicate the extension without much benefit.
What people think about this?

Alexey