> >I guess one of the existing lines of the file could be extended with
> >more info, as a hack....
> 
> Exactly! Or perhaps the file could be left just the way it is, and a parallel 
> file added, maybe using SkipLists...
> 

We should really take a good look at what should go in that file before
we update the format again.  Threading info is part of it, to be sure. 
Pop's "UID" field would be nice as well, so that "leave messages on
server" would work better.  Mailing lists would be nice, too, so that
you can filter directly based on the mailing list (for mailing lists
that have the required headers).

An extensible format would be especially nice.  The challenging part is
to make it be faster than what we have now!  Historically, the index
file  has been saved in a text format so that it never goes wrong. 
However, this doesn't seem so improtant when the index is essentially a
cache of information that is already in the messages file.  I think the
basic mechanism we'd want is, a way to save dictionaries whose keys are
strings, and whose values are either strings or integers.  Then we could
add fields as desired.  Perhaps a header would have a list of fields
that are loaded at all -- attempts to access fields not in the index
file could then fall back on reading the message and parsing the header
out the (very) slow way.


-Lex