From: Andrew Gierth (andrew@erlenstar.demon.co.uk)
Date: Wed Mar 01 2000 - 00:08:54 CST
>>>>> "Brad" == Brad Templeton <brad@templetons.com> writes:
>> 1. the message-id versioning stuff imposes significant constraints
>> on the design of the history mechanism. The fact that it happens
>> to be possible with INN's dbz is not a convincing argument.
Brad> What are those constraints?
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> I've never liked the xref additions, though. I've always felt
Brad> that replace-in-place is the right answer.
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.
-- Andrew.