From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Fri Mar 03 2000 - 06:35:47 CST
In <ylhfepezft.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes:
>It's certainly not simple. In INN, like most current news servers, the
>keys to the history database are not message IDs; they're hashed forms of
>message IDs. The actual message ID isn't stored anywhere in history in
>current INN. So you'd need to use an extra external database to do the
>version number mappings for Replaces.
I still don't see the problem. I assume the hashed forms are long enough
that is can reasonably be assumed that clashes will never occur. Consider
the following example:
Original Message-ID: <myuniquepart@mysite.example> for which the hash is
<123123>
So the history file contains:
<123123> comp.foo 1000 (or something like that)
and the dbz index maps <myuniquepart@mysite.example> into the address of
that history line.
Now comes Message-ID: <myuniquepart$v=1$xxx@mysite.example> for which the
hash is <456456>
with Replaces: <myuniquepart@mysite.example> ; usage=revise
After which the history file will contain:
<123123> comp.foo 1000
...
...
...
<456456> comp.foo 1027
<123123> comp.foo 1027
And article 1000 in comp.foo will be absent (and even the history file
will reflect that absence after the next expiry run).
And the dbz index maps <myuniquepart$v=1$xxx@mysite.example> into the
address of the <456456> and it maps <myuniquepart@mysite.example> into
the address of the SECOND <123123> line (because we have arranged that dbz
always maps into the latest of any duplicates).
So anyone who does an NNTP ARTICLE request for
<myuniquepart@mysite.example> will in fact get shown article #1027.
Now the Xref header or article #1027 should contain:
Xref: comp.foo:1027 revise:1000
The way you do this is that, when you encounter the Replaces: header, and
*before* you start tinkering with the history file and cancelling the old
article, you retrieve its headers from your database, look at its Xref
header, and note that its article number in comp.foo was 1000 (or, come to
think of it, you can probably get the same information from the original
history file entry). After that, you destroy the old copy and put the
extra entry in the history file as already shown.
So, what is the problem?
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5