30 lines
1.4 KiB
Plaintext
30 lines
1.4 KiB
Plaintext
MBOX-Line: From janssen at parc.com Tue Mar 13 09:29:37 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bill Janssen <janssen@parc.com>
|
|
Date: Fri Jun 8 12:34:38 2018
|
|
Subject: [Imap-protocol] SEARCH restricted to one mailbox? Extensions?
|
|
In-Reply-To: <45F6A2E4.3060502@aol.com>
|
|
References: <07Mar12.152936pst."57996"@synergy1.parc.xerox.com>
|
|
<1173743673.9167.65.camel@hurina> <45F6A2E4.3060502@aol.com>
|
|
Message-ID: <07Mar13.082943pst."57996"@synergy1.parc.xerox.com>
|
|
|
|
> 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.
|
|
|
|
How would the client know to SELECT it?
|
|
|
|
I was actually thinking of doing what Timo reminded me of yesterday,
|
|
using a CREATE/SELECT combo, which would create a new mailbox the name
|
|
of which would be the query, and would then rescan the query if it was
|
|
selected. They would be persistent in the server, but since they would
|
|
be smart virtual mailboxes, this wouldn't be a big cost.
|
|
|
|
Bill
|
|
|