On Thu, Feb 16, 2012 at 03:21:55PM +0000, Tony Finch wrote: > Bron Gondwana <[email protected]> wrote: > > On Thu, Feb 16, 2012 at 01:06:11PM +0000, Tony Finch wrote: > > > Bron Gondwana <[email protected]> wrote: > > > > > > > > Not really. Existing servers would be a lot more efficient with a query > > > > which limited to a single "folder", for sure - because they could > > > > optimise > > > > it. But it's no different than an SQL query across a partitioned table. > > > > It means your in-memory-state needs to be big enough to accommodate all > > > > the mailboxes that might be in the regular searches, of course. > > > > > > Have you seen UW-IMAP's in-memory state? :-) > > > > Nup - I've seen Cyrus' though. It could be trimmed considerably if we > > had to... > > The problem is UW-IMAP is structured so it can only handle one mailbox at > a time.
Cyrus too. Which is a reason for not forcing the model of "one big pool". I'm not committed to one big pool - if there's a syntax for joining smaller pools together to sort/search across them. This is one of the "more work for the server, less for the client" options, where we assume people writing servers are slightly more clueful. Besides, they'll have a test to run :) Bron. _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
