> Al continues:
> Earl, where does this stand vs. your list of to-do's for MHonArc 3?
I am considering it. It is possible to implement support for links
across archives, but there may be a performance problem along with a
limitation that the links can go back (ie. references) but not forward
(otherwise you basically have one archive again).
May I brainstorm a little? I think there are two issues: how many
messages you hold in the database for threading and whether the message
pages are in one flat directory or in a hierarchical storage scheme.
My resident pipe dream has some performance hits, but not unbounded size
of anything (directory, database, etc.). The ideas hanging around in
my head include:
- primary key in the database is the message-ID. This will
slow MHonArc down a little but clean up the logic.
- decouple the management of the linking database from the
binning of message files. An example database strategy is
a max count of messages. This window slides along. The messages
files have a storage scheme which follows an expression using available
variables including $ID_HASH$ which is a key generated off
the Message-ID.
This lets messages be linked forward and back. The links that
get dropped on the floor are those that link across time spans
where there are many, many, intervening messages.
Consider the quantities involved in lynx-dev. This list runs
about 1000 messages a month. Threads run on from 3 days to 2
weeks on the outside. So a break at every month-end breaks about
10% of threads, while breaking links that leap over, say, 1000
intervening messages would probably damage less than 1% of the
actual threads. Anyhow, that's what I was thinking.
--
Al Gilman
