From: Bill Davidsen (davidsen@prodigy.com)
Date: Wed Mar 08 2000 - 11:06:56 CST
chl@clw.cs.man.ac.uk (Charles Lindsey) wrote:
> In <200003062115.QAA24395@darkstar.prodigy.com> davidsen@prodigy.com (Bill Davidsen) writes:
>
> >You miss the point, you can't have duplicate entries in a history file
> >because they're not allowed. The way a server prevents getting multiple
> >copies of an article from multiple feeds is to reject an article with
> >the same message-id (or hash thereof). In this case "the right thing" is
> >to prevent duplicates, so there's no logic to implement the forbidden.
>
> No, I think you are missing the point here. If an article appears with a
> Message-ID that is already in your History, you say "no thank you". So if
> it is already in your History twice, you still say "no thank you".
The reason dbz doesn't cope with an entry in the database twice is that
it can't happen. So allowing this is not a minor tweak, it's a whole
change in base implementation rules.
> Actually, you never realize it was there twice, because dbz only leads
> you to the latest, which is enough to trigger the "no thank you" response.
>
> >Oh, and makedbz cares very much, it's not just expire.
>
> I presume makedbz is what you use to recreate the whole dbz database if
> it got corrupted/whatever? In that case, yes, it needs to be hacked so it
> points to the latest (i.e., scanning your History from the start, if you
> find dbz already pointing to an entry for that ID, you overwrite the
> pointer with the new ID).
Same issue...
> Well in an implementation where the History file records are of a fixed
> length (which I gather they are in this scenario) then changing the API in
> situ is fine (it's what Brad has been asking for all along). In fact, the
> only reason for the (complicated?) solution of duplicate entries was to
> avoid the need to rewrite entries in the middle of the traditional
> variable-length record History file.
Still not needed, although it could be done for fixed length records.
When the *first* generation of an article subject to replacement
arrives, the API can point to an alternate lookup which gracefully
handles changes.
On the whole topic:
- I haven't changed my mind that this is a bad idea. A message-id
should be unique, and I should get one thing one day and something else
the next.
- I think it's reasonable to require that an article be marked as
replacable so that the server can handle it specially. Not MUST be CAN
to be clear.
- while we have said that this can be inefficient to a degree because it
is seldom used, we should put some protection in the standard such that
an evil entity can't send up a million of these and bring all the
servers on the net to their knees. Validation required.
-- -bill davidsen (davidsen@prodigy.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me