Incremental squat updates and IMAP "SCAN" extension

[David Carter]

Both at:

   http://www-uxsup.csx.cam.ac.uk/~dpc22/cyrus/patches/2.3cvs/

squat-incremental.patch
=======================

Compare and contrast:

   $ squatter -v -i user/dpc22/spam
   Indexing mailbox user/dpc22/spam... Indexed 1 messages
     (1810 bytes) into 32247004 index bytes in 4 seconds

   $ squatter -v user/dpc22/spam
   Indexing mailbox user/dpc22/spam... Indexed 12519 messages
     (38270058 bytes) into 32247004 index bytes in 140 seconds

Both from a standing start on a freshly mounted filesystem. This patch 
includes the fix that I sent in on Monday. It also automatically clears 
out empty trie branches generated by old versions of squatter in both 
incremental and normal operation.

scan.patch
==========

Adds the undocumented SCAN extension to Cyrus for cross mailbox searches. 
Plumbs into squat_search_list_docs(), just like SEARCH.

   . SCAN "" * dpc22
   * LIST () "/" "test/1"
   * LIST () "/" "test/2"
   * LIST () "/" "t"
   . OK Completed (0.000 secs 4 calls)

Not sure why the responses are "LIST" rather than "SCAN", but that's what 
UW IMAP does. This exists solely because cross mailbox searches only work 
in PINE and ALPINE if the SCAN command is there. Otherwise ALPINE moans:

   Scan not valid on this IMAP server.

Why they insist on using SCAN is a bit of a mystery. ALPINE opens an IMAP 
connection for each mailbox that it wants to search, presumably in order 
to run the searches in parallel (and grind the server into the ground). 
The SCAN commands then become e.g:

   . SCAN "test/" "1" dpc22

which could just as easily be done using EXAMINE and SEARCH.

Things would probably go much faster searching one mailbox at a time 
rather that adding random access disk I/O just for the hell of it.

-- 
David Carter                             Email: David.Carter at ucs.cam.ac.uk
University Computing Service,            Phone: (01223) 334502
New Museums Site, Pembroke Street,       Fax:   (01223) 334679
Cambridge UK. CB2 3QH.