From: Brad Templeton (brad@templetons.com)
Date: Wed Mar 01 2000 - 03:57:51 CST
On Wed, Mar 01, 2000 at 09:40:20AM +0000, Andrew Gierth wrote:
> Still doesn't solve the problem. Part of the functionality that you're
> trying to add is for a newsreader to be able to tell "this new article
> replaces that old one, we've already read the old one, no need to show
> the new article".
>
> Since tracking which articles have been read is almost invariably done
> by article number, this means that there must be _some_ way to connect
> the new article with the old article number. The draft says that this
> is done via Xref, and my objection at the start of this thread is that
> this would be expensive at best and impractical at worst.
Well, to that I agree. I have always preferred replace-in place. However
it's not dreadfully hard. You look at the xref, you see if it refers
to an article that was read, and you don't show it if so. You do
want to know if it was truly read, or marked read because it didn't
exist. However, that should only happen in the same session so it
should work.
You had indicated problems with the history database lookups.
>
> (Reusing the old article number is in any case not possible over
> extended periods of time, as it would play hell with group low water
> marks.)
I had intended it for article updates more than very long chains, however
in the event of its use in very long chains options one could move
the article into its lowest slot within the regular low and high water mark.
The result would be that some people would see it again, but only
if their newsreader was an old one. New ones would have the option
of doing the more complex tracking people have planned for without
in-place replacement.
Not the most satisfactory solution, but still better than the proposal,
which leaves users of old newsreaders always seeing updates. At least
under my proposal users of all newsreaders never see short-term updates
and users of older newsreaders may see a *few* of the long-term updates
rather than all of them! Users of new newsreaders that understand
replacement see the same thing under both systems.
However, remember my main goal here was for short-term updates, with
version numbering an added feature for long term ones -- both supersedes
and replaces.
Right now the vast majority of uses I see of supersedes would really rather
have replaces. In fact supersedes, meaning "replace this but show
everybody the new one whether they read the old or not" seems a much
less likely thing to desire.
Often I post an article and later see a minor error or typo or
whatever. No way I am going to supersede, it would be more annoying
to point out my typo to everybody than to leave it unfixed. Sadly,
since the modification of my plan for Replaces leaves all users of
old newsreaders still seeing the update, I predict it will remain
unused for my intended purpose for some time to come. Sigh.
However, I still want to know about the original issue. Why do any
of these features -- replacement and version-numbers in message-ids,
place a limit on how one does the history database or article numbering?