From: Russ Allbery (rra@stanford.edu)
Date: Fri Mar 03 2000 - 14:56:26 CST
Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
> 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).
You can't do that to INN dbz; it doesn't allow for duplicates. Changing
that would be severe pain. It would be far easier to use a separate
external database just for replacements.
INN's dbz code doesn't look much, if anything, like C News's at this
point.
What INN's dbz code *will* allow in INN 2.4 or thereabouts (if I can ever
find time to work on anything other than fighting fires at work :/) is
in-place updates of the storage API token associated with a given hash.
So you can potentially solve the problem in INN that way. But it doesn't
support that currently either.
> 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.
You can't get that information from the history file in all (or even most)
cases. INN's history file currently contains the message ID hash, the
expiration times, and the storage API token. The storage API token has no
relation to the article number and doesn't contain equivalent information.
Opening the article and parsing its headers on each Replaces is just
really ugly. Doable for a single news system, but really ugly. In a
clustered environment, I think you'd have to do this separately on each
slave since the article has likely already expired from the master, making
this even uglier.
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>