Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!watmath!looking!brad
From: brad@looking.on.ca (Brad Templeton)
Newsgroups: news.software.b
Subject: How about a 'Replaces' mechanism in addition to supersedes?
Message-ID: <17596@looking.on.ca>
Date: 20 Sep 89 00:30:05 GMT
Organization: Looking Glass Software Limited, Waterloo ON
Lines: 77
Class: query

With more thought I have decided that what I really need (and what might
be useful to the net in general) is a mechanism to allow one news
article to replace another.

By this I mean that unlike a supersedes, where the old article is
cancelled, and the replacement takes the next available article
number, we would have a 'Replaces:' (or something like it) where
the new article actually replaces the old, getting the same
article number.

With supersedes (or the simple cancel and repost) if you have read
an old version, you still get the new version presented to you.  For
those who didn't read the old one, they only see one article, but it's
out of order.

With a replacment mechanism you would never see the article more than
once, unless you went back to look.  You would not see articles out of
order, however, except for the various other reasons that happens.
(See another thread)

There are a couple of ways that replacement could be done:

1) A Replaces: header that is just like Supersedes:  For backward
compatibility, if an article has a Supersedes and an empty (or identical)
'Replaces:', a Replacement is done.  Sites with semi-old software would
ignore the 'Replaces' and do the supersedes of course.
	
	(Unfortunately, few sites understand supersedes as it is, so
	backwards compatibility with them may not be that useful.)

2) Replacement articles move out with the *same* message-id, but a later
   date of posting.  If inews sees an article come in with a duplicate
   message id, instead of throwing it away, it checks the date from the
   history file (which it's already half-way to looking at).  If the new
   message has a greater date, it 'Replaces:' the old.

   For redundency, such a lookup and replace might only be done if the
   message has some sort of replacement header.

   Sites with old software will toss such articles unfortunately.

Now of course, replacement does allow a bit of revisionism to take place.
But I doubt that is a big worry.  Forgery also presents some ugly problems.
No doubt some disk-rich sites can just move replaced articles to a
'to-be-deleted' spool directory, and also make sure there is a header
in every replaced article stating that it is a replacement, version N, of
this article.

It is also important to allow replacements to 're-create' cancelled
articles.   This is important, since for sites with old software, you may
have to issue a cancel of the old article anyway before replacing it.
But this would also allow one to 'un-cancel' an article.  Unfortunately,
it presents problems in the case of multiple feeds and messages that get
out of order, where a late cancel might come in and zap the replacement.
(Perhaps cancel messages must include the version number to cancel a
replacement?)

In conclusion, I suspect the following is the preferred method:

	A) Replacement messages have a line of the form:
		Replaces: <message-id> <version>
	but they have a unique message-id.   Such messages replace
	the actual files for <message-id>, or recreate some if cancelled.
	The addition or deletion of groups must also be dealt with.
	Replacement takes place only if the message is missing or the date
	on the replacement exceeds the date on the original.

	One always replaces using the *original* message-id, no matter how
	many replacements occur.  The version number is a comment for the
	reader.

	Cancel messages may arrive for the original or subsequent versions,
	using the unique message-id of each message.  A cancel for the
	original does not cancel any replacements, unless the cancel
	message has something in it to indicate it cancels all versions.
-- 
Brad Templeton, Looking Glass Software Ltd.  --  Waterloo, Ontario 519/884-7473