From: Brad Templeton (brad@templetons.com)
Date: Wed Mar 01 2000 - 02:22:00 CST
On Wed, Mar 01, 2000 at 06:08:54AM +0000, Andrew Gierth wrote:
> >>>>> "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>.)
Well, not if one does replace with the same article number, as I
had always intended it when I proposed this header. However, it is
not strictly necessary to alter the record for <foo@bar> to attain this
goal. In particular, article fetch by message-id is currently not a
very common thing, and in particular, fetch by message-id of a replaced
article is unlikely to become common, even in a suck feed.
So the implementation, with any history mechanism is as follows:
a) Fetch <foo@bar>. Note that article is not present. (It was
replaced, after all.)
b) Fetch special record named V<foo@bar> or some
other record not to collide with actual message-ids.
This can be a pointer to the current record for <foo@bar>
(actual message-id, contents or just the number itself)
This works for any version you might wish to fetch.
c) If you can't have a rewritable record *at all*, which I doubt
because the pointer need not be in the same database, there are
much fewer of the pointers, then you would have to chain until you
found the last one. But this is a very rare operation, and
after all, the alternative is to return "not present" which is
not a very good result. The chaining, in this unlikely situation,
seems worth it.
So no, I do not see any constraint on how I implement my main history
database required by the ability to version.
>
> 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.
The number of articles involved in version chaining will be several orders
of magnitude less than the total article volume. Effectively, it will
be regular postings and corrected postings. Fetch by message-id can
be very common but fetch by message ID of since-replaced articles will not
be as far as I can see..