MBOX-Line: From snowjn at aol.com  Wed Mar 14 11:46:41 2007
To: imap-protocol@u.washington.edu
From: John Snow <snowjn@aol.com>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] SEARCH restricted to one mailbox?  Extensions?
In-Reply-To: <45F83CCD.2050808@isode.com>
References: <07Mar12.152936pst."57996"@synergy1.parc.xerox.com>	<1173743673.9167.65.camel@hurina>
	<45F6A2E4.3060502@aol.com> <45F83CCD.2050808@isode.com>
Message-ID: <45F84311.3080906@aol.com>



alexey.melnikov@isode.com wrote:
> John Snow wrote:
>
>> How about combining the multiple mailbox search with a select command 
>> to create a temporary mailbox view that contains the search result?  
>> Since it doesn't exists as a listable mailbox, then it can't be the 
>> destination for a copy command, avoiding any issue of which 
>> underlying mailbox should be the destination.  The untagged exists 
>> response response would show the number of hits to the search query.  
>> Also, the result set could be referenced by sequence number instead 
>> of the individual UIDs as returned by the standard search command.
>
> This looks similar to VFOLDER extension: 
> <http://tools.ietf.org/html/draft-ietf-lemonade-vfolder-01>
>
Sort of.   In vfolder, the search criteria is stored to create a view 
that is a subset of an existing mailbox. In that case, it can easily be 
treated the same as any other mailbox.  My hope is to expand that beyond 
a single mailbox.  I think creating a server stored view is 
unnecessary.  The extension aware client can create the combined view on 
the fly.  I see it more as an extension to search than a new virtual 
mailbox.   In a standard search, the results are only updated when the 
client issues a new search and not pushed from the server.


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