Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!watmath!looking!brad
From: brad@looking.on.ca (Brad Templeton)
Newsgroups: news.software.b
Subject: Supersedes problems with rapid-fire articles
Message-ID: <5200@looking.on.ca>
Date: 29 Aug 89 05:51:24 GMT
Organization: Looking Glass Software Limited, Waterloo ON
Lines: 51
Class: information, original

As a recent experiment, I decided to give away the ClariNet wireservice
articles on the voyager flyby to USENET by cross-posting them to
sci.astro.

When a newswire does a major story it releases sometimes dozens of new
versions of that story during the day, all under the same keyword.

Our interface currently uses the Supersedes header to have each version
replace the previous one.

Unfortunately, we got a few complaints.  This is in part due to the fact
that several sites, including watmath (our main connection) are not
handling supersedes as yet.   Anybody have any ideas on how many sites
are running news software that is old enough to not handle supersedes?

Admittedly, nobody on the net has ever made serious use of this header
before. 

Furthermore there may be another problem.  If two articles in a chain come
in between two calls to sendbatch, the first supersedes the other, erasing
it.  Unfortunately the erased article contains the supersedes line needed
to cancel the article that went out in the first sendbatch.  So that article
never gets deleted.   This means supersedes and batching just don't seem
to work well together if articles come rapidly, either from the wire or
by hand when people make corrections.

One messy solution is to give up on supersedes and just use cancel
messages -- lots and lots of them.  I could see generating over 100 per
day, although few would make it past the first few downstream levels.

Any other thoughts on how we might make supersedes work?

A long term idea involves a new header, which would allow versions of
articles.  In such a case, we could just say, "this is version 1, this is
version 2" etc. and all articles would replace *all* their previous versions
as they arrived.

Alternately no version numbers would be needed.  One could simply use the
date field.  If a message had a "Supersedes" header of *any* sort on it,
the software would parse the message-id (the real one, not the dummy
supersedes argument) and remove the version number prefix.  It would then
cancel/replace all messages with a matching ID but an older date.

In fact, although it doesn't match current software, I think it would be
neat to have this work when a "duplicate" article comes in.  If
<abc@def> comes in, and you already have <abc@def> you check the dates.
If they are the same, or the incoming message is older, throw away the
incoming message.   If the incoming message is newer, cancel the old
one and put in the new, but with the same message-id!
-- 
Brad Templeton, Looking Glass Software Ltd.  --  Waterloo, Ontario 519/884-7473