From: Andrew Gierth (andrew@erlenstar.demon.co.uk)
Date: Wed Mar 01 2000 - 02:35:24 CST
>>>>> "Brad" == Brad Templeton <brad@templetons.com> writes:
>> The requirement that given an existing (unversioned) message-id
>> <foo@bar>, that it be possible to update that (whether by adding a
>> duplicate entry or by other means) to refer to a different article.
>> (The arrival of article <foo$n=2$xxx@bar> changes the result of doing
>> a lookup of <foo@bar>.)
Brad> Well, not if one does replace with the same article number,
Article numbers don't have anything to do with it. My history file,
like that of most current servers, is a mapping from message-id-digest
to storage-location; the storage location has no relationship to the
group or article number. I don't even store the actual message-id in
the history.
[replacement in place]
>> That does not solve the implementation problems. In particular, the
>> requirement to locate the article numbers of the article being
>> replaced is still a show-stopper on clustered systems.
Brad> The number of articles involved in version chaining will be
Brad> several orders of magnitude less than the total article volume.
Brad> Effectively, it will be regular postings and corrected
Brad> postings. Fetch by message-id can be very common but fetch by
Brad> message ID of since-replaced articles will not be as far as I
Brad> can see..
This is irrelevent. The problem is what to do about fetch by _number_
of a replaced article. You want a fetch of the old article's number to
return the new article instead; this requires that when the system
which does the numbering receives the new article, it must be able to
find the article numbers that were used for the old article. This is a
sticking point on a cluster system, because even though the old
article is still in the reader spools, it has likely expired from the
hub itself.
-- Andrew.