From: Brad Templeton (brad@templetons.com)
Date: Wed Mar 01 2000 - 02:50:15 CST
On Wed, Mar 01, 2000 at 08:35:24AM +0000, Andrew Gierth wrote:
> >>>>> "Brad" == Brad Templeton <brad@templetons.com> writes:
>
> >> 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> Well, not if one does replace with the same article number,
>
> Article numbers don't have anything to do with it. My history file,
> like that of most current servers, is a mapping from message-id-digest
> to storage-location; the storage location has no relationship to the
> group or article number. I don't even store the actual message-id in
> the history.
Yes, but is it not the case that you have the ability to store a pointer
of some kind, any kind at the storage location? If you do, then it
becomes easy to do the indirection. You certainly have to have the
ability to say "This article is no longer here" and wherever you say
that you probably have an ability to store a pointer saying, "and here
is where you can now find it."
But even if you don't, all I point out is that all you really need
is the ability to say "It's gone now" (Which is required by existing
rules) and the ability to somehow, somewhere, in some small database,
look up where it's gone.
>
> Brad> message ID of since-replaced articles will not be as far as I
> Brad> can see..
>
> This is irrelevent. The problem is what to do about fetch by _number_
> of a replaced article. You want a fetch of the old article's number to
> return the new article instead; this requires that when the system
> which does the numbering receives the new article, it must be able to
> find the article numbers that were used for the old article. This is a
> sticking point on a cluster system, because even though the old
> article is still in the reader spools, it has likely expired from the
> hub itself.
Ah. You had expressed the problem is "how do I look up <foo@bar>" and
did not ask this question. I was saying it didn't put constraints on
the history database, which maps from message-id to article location
(and sometimes number.)
Generally, I had not expected replacement to mandate that fetches of
the old *number* should work, though of course that would be the case
with my preferred implementation of replace-in-place.
In fact, generally I was *not* expecting it to work. If article 30
replaces article 20, it should *not* be the case that fetches of either
will return the same article. That would only confuse newsreaders.
While again, I think the right answer is to change article 20 and not
generate a new article number, others here don't like that, they want
a new article. In that case, fetching 20 should return nothing, or
some signal saying "replaced by X" (where X could be 30 or the new
message-id or both) if that is convenient to say.
But I would think that returning nothing is acceptable, though being
able to give the reader a pointer it can understand is also good.
Now the only issue that comes out of this is what happens when a
replacement takes place between the time the user fetches the overview
and the time she reads an article. In this case for old readers it
is vital that a fetch of the old article return nothing, because otherwise
the new one will re-appear as an apparent duplicate. A smarter
newsreader, however, might very well remember the message-id of the
articles it is fetching, and when it tries to fetch and sees it is gone,
looks for the replacement via message-id. Then it finds it at article
30 and is able to present it -- and mark article 30 as read, which is
very important.
Another way a smart newsreader might work is it might fetch 20 and get
back a code saying "moved to 30" in which case it might do the same
thing. NNTP coudl support such a code if desired, as could any other
fetch library.