To do list for Funes. Never ending! Write <nelson@monkey.org> if you
have ideas on these.

* Command line interface
  Allow for command line arguments to more easily specify search terms,
  but make it interface well with Lucene's QueryParser syntax. Here's a
  possible usage() string.
        return
            "Usage: Search [options] query string\n" +
            "  Search options: (default is search all, optiones stackable)\n" +
            "    -a, --author      Search author\n" +
            "    -r, --recipients  Search recipients\n" +
            "    -b, --body        Search body\n" +
            "    -s, --subject     Search subject\n" +
            "\n" +
            "  Retrieval options:\n" +
            "    -c, --count       Retrieve count of messages only\n" +
            "    -h  Retrieve header info only\n" +
            "    -v  Retrieve entire message from file\n";

* Date searches
  Make it easy to do searches via date ranges.

* ByteRangeInputStream
  Implement block read()s, not just single byte reads.
  Use skip to read ahead, and verify that on a file stream this does a
  fast seek().

* Make a clean install.
  Debian package?

* Indexing MIME types
  Index as many MIME types as possible, not just text.

* Input massaging
  Skip over signatures, other user-specified things they don't want to
  index or retrieve.

* Fold email addresses on indexing
  Use address book to infer the "true" email address as it goes by in
  indexing. Ie: if it sees the address "nelson@monkey.org", it should
  also index it by the string (Nelson Minar), so that searches for
  "Minar" hit even if the string "Minar" was never in the original.

* Generalize folding email addresses
  Email address folding is only one kind of treating content
  specially, not actually indexing it as-is. Consider doing this to
  other fields, too

* Searching all fields
  Default search should be for everything, not just body! How to feed
  this in to Lucene's QueryParser?

* Tokenizing email address
  Email addresses need to be tokenized so you can search on just parts.
  But how?

* Using Lucene's parsing hooks
  Some of the parsing we do is better done in Lucene - analyzer, etc.

* Customizing parsing
  Allow the user to specify stemmer, etc.

* Tuning of weights
  Weight different fields based on importance - email address searches

* Tuning sort order
  Some queries may want to sort by date, or by hit quality of a
  particular field (ie - subject order, not body order).

* Optimize indexing
  All this parsing by Javamail is really slow. Is there a way to use
  StubMail connected to our own reader, and avoid the statefulness of
  Javamail?

* Multiple mail sources
  Support indexing email from various sources, not just mbox files.
  This goal may contradict "Optimize indexing" todo item.

* Index directory management
  Enable the user to specify the location of their index directory.
  Have better software for managing index, etc.
 
* Incremental indexing
  Use Lucene's incremental indexing capability so archives can be
  updated live, as email comes in (procmail!)

* Profiling
  Why is it so slow? Make it faster!

* Compare to other tools.
  Research other search tools out there - Eyebrowse, grepmail, etc.
  Write up a feature comparison, learn from their good ideas.

* Refactoring
  As features are added, Search and Index need to be factored into
  many useful classes.

* Test framework
  Need a much better way to test things, and soon! Maybe borrow
  grepmail's test cases? It has good ones.
