INTERNET-DRAFT                               Charles H. Lindsey
Usenet Format Working Group                  University of Manchester
                                             April 2001

6.15.2.2. Implementation and Use Note

6.15.2.2.  Implementation and Use Note
[Here is the implementation technique that we discussed, based on the
use of a conventional History file. This is a sanity check for our own
use, not intended to go in the final text. There are two cases to
consider:
A. Traditional implementations (e.g. CNEWS) where each History file line
includes a full message-identifier plus an item for each group in which
the article appears. Thus History file entries are of variable length,
and it is impractical to update them in situ.
B. History files made up of fixed length records (e.g. as proposed for
INN), which enables entries to be overwritten in situ. The History line
typically contains a hash of the message identifier plus some pointer to
an object representing the article as stored.

We consider the traditional case first:

1A. Ensure that the implementation of DBZ is not upset if the same key
is attempted to be stored a second time, and that such a key always
retrieves the latest record indexed by that key.

2A. Additions to the History file are always made at the end. Removals
or changes to existing entries are only made by the expire program. An
entry for a Replaced (or otherwise cancelled) article will remain until,
first, the expire program removes the links to the articles that are no
longer stored, and later on removes the entire entry according to its
expiry date. For every entry containing a '$v=n' followed by random-
dollars-sequences there will be an immediately following entry identical
but for the omission of that '$v=n' and of the random-dollars-sequences.
Thus there may be several entries with identical message-ids but,
because of the change to DBZ just described, only the most recent will
ever be seen except by programs that access the History file directly,
rather than by its index.