From: Andrew Gierth (andrew@erlenstar.demon.co.uk)
Date: Mon Nov 05 2001 - 12:45:50 CST
>>>>> "Charles" == Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
>> FAQ authors concerned about this problem put the version number or
>> last updated date in the subject line, which allows a killfile to
>> do exactly that. (If you only want to see my FAQ when it changes,
>> then killfile on the whole subject; if you never want to see it
>> even when it changes, then use a substring or regexp match on the
>> constant part of the subject.)
Charles> I don't recall seeing a FAQ that routinely did that. Can you
Charles> point me to some current examples?
The proportion of FAQs that use that method seems fairly low. You can
find a complete list by downloading the LoPIP and looking for entries
with '*' in the subject line. Here are some examples from the last
few posts in news.answers:
[alt.fan.sandra-bullock] FAQ: The alt.fan.sandra-bullock FAQ Ver 3.13
misc.writing Recommended Reading List [31May2001]
Calendar FAQ, v. 2.4 (modified 28 Oct 2001) Part 1/3
Calendar FAQ, v. 2.4 (modified 28 Oct 2001) Part 3/3
Calendar FAQ, v. 2.4 (modified 28 Oct 2001) Part 2/3
[alt.fan.sandra-bullock] a.f.s-b Web Site List Ver 2.01
The Email Abuse FAQ, Version 2.02
[de.comp.lang.perl.misc] Erst lesen - dann posten <23/07/2001>
comp.sys.amstrad.8bit FAQ v1.26 1/1
My own FAQ (for comp.unix.programmer) was last posted about a week ago
and has the subject line: Unix Programming FAQ (v1.37)
>> The original proposals involving putting the old article number in
>> Xref are not implementable without _serious_ difficulty on
>> clusters where article numbering is done independently of the main
>> spool, because the numbering server (which generates the xref)
>> will have no feasible way to determine the original number.
Charles> I find it hard to understand this problem. You are saying
Charles> that the numbering server cannot know the article number of
Charles> the replaced article (given only its message-id). And yet
Charles> all the slave servers know it, and any newsreader can find
Charles> it at the drop of a hat. Please explain further.
The numbering server only has enough history file to prevent acceptance
of old articles, and it doesn't have an overview file at all, and it
probably has a retention of no more than a few hours (if that).
Normally, when articles arrive at the numbering server, the Xref is
constructed by looking up each newsgroup in the active file (which is
hashed and incore), incrementing the highmark and stuffing it in the
header value, a matter of a few microseconds.
When an article with a Replaces header arrives, the numbering server
has to try and find the numbers of the target article. It has no
locally-stored information about this _at all_, so the only thing it
can do is to talk to the slave servers. Note that most transit servers
split incoming and outgoing into separate programs, so the incoming
process has no particularly convenient method of making outgoing
connections; then it has to be configured to know where the slaves are
(the outgoing side will already know this, but not the incoming); then
it has to be able to issue a suitable command on the slave (and the
incoming feed process on the slave may not support anything except
transfer commands, so it might have to connect as though it were a
reader, which then involves all the reader-side authentication
checks). If the numbering server is a multiplexed server like INN,
then the entire inbound feed is stalled while all this happens. And
even if all is going well, the slave is quite probably going to have
to fetch the old Xref from disk, so you're quite possibly talking 10ms
_minimum_ to do the whole job - when a new article is coming at you
every 50-60ms at peak times.
Introducing this kind of cross-dependency into a system which is already
uncomfortably hairy is going to cause no end of headaches for both the
implementor and the admin(s). Given the kind of load that we have to
cope with these days, you really seriously want to keep your system as
simple and clean as possible, with straightforward data paths and enough
buffering slack so that things don't go down in a heap just because one
box got a bit overloaded.
-- Andrew.