From: Andrew Gierth (andrew@erlenstar.demon.co.uk)
Date: Fri Mar 03 2000 - 11:52:49 CST
>>>>> "Charles" == Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
Charles> Now comes Message-ID: <myuniquepart$v=1$xxx@mysite.example>
Charles> for which the hash is <456456>
Charles> with Replaces: <myuniquepart@mysite.example> ; usage=revise
Charles> After which the history file will contain:
Charles> <123123> comp.foo 1000
Charles> ...
Charles> ...
Charles> ...
Charles> <456456> comp.foo 1027
Charles> <123123> comp.foo 1027
Charles> And article 1000 in comp.foo will be absent (and even the
Charles> history file will reflect that absence after the next expiry
Charles> run).
This is the part I have a problem with (in my code, which is not dbz).
In all other cases message-ids are _unique_ identifiers, but here we
suddenly have one that is duplicated.
Charles> Now the Xref header or article #1027 should contain:
Charles> Xref: comp.foo:1027 revise:1000
Charles> The way you do this is that, when you encounter the
Charles> Replaces: header, and *before* you start tinkering with the
Charles> history file and cancelling the old article, you retrieve
Charles> its headers from your database,
And this is the other part I have a problem with - in a cluster system
the Xref is generated in the hub, and so this step fails if the article
being replaced has expired from the hub's spool (which is small compared
to that of the reader systems).
(The article number is not available from the history in any organization
other than traditional spool.)
-- Andrew.