mhonarc-users

MAXSIZE - poor man's windowing

1999-01-05 01:07:44

So here's a crazy high level idea about how to implement windowing
(i.e. having MHonArc only consider recent parts of the archive rather
than the whole thing when indexing new messages.) What do people
think?  Here's the scenario:

-------------------

<!-- The new resource, called <WINDOW>, can be set to an -->
<!-- integer greater or equal to 1.                      -->

<WINDOW>
3
</WINDOW>
<IDXSIZE>
100
</IDXSIZE>
<MULTIPG>

So I start adding messages to the archive, and it grows and
grows... at 101 messages we have two date index pages (due to IDXSIZE
and MULTIPG).  At 201 we get three date index pages. So far everything
is normal.

However, when we get to message 301, it gets more interesting. The
database shrinks to size 200, (IDXSIZE * (WINDOW - 1)). The shrinkage
is like a MAXSIZE shrinkage, however the existing html message files
do not get deleted, nor does the index file we just orphaned. Both
stick around and are legacy html files; i.e. perfectly good HTML files
that have no representation in the MHonArc database.

Then as messages get added to the archive, eventually the database
size reaches > (WINDOW * IDXSIZE) and we repeat the process.

-------------------------------------------------------------

Here are the advantages/disadvantages I thought of; I'm sure there are
others.

Advantages
----------

* MHonArc would have the ability to handle large archives with a small
  database (saving on both memory and processing time)

* It might be sane to implement

Disadvanatages
--------------

* It's not a perfectly generalized solution (i.e. your window size
  is quantized by IDXSIZE)

* It may not offer enough advantages over stright MAXSIZE to be worth
  adding complexity to the code.

<Prev in Thread] Current Thread [Next in Thread>
  • MAXSIZE - poor man's windowing, Jeff Breidenbach <=