Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!samsung!olivea!jerry
From: jerry@olivey.ATC.Olivetti.Com (Jerry Aguirre)
Newsgroups: news.software.b
Subject: Re: Expire by Date:
Summary: Set article file modified time to posting date
Message-ID: <50464@olivea.atc.olivetti.com>
Date: 15 Mar 91 01:17:54 GMT
References: <1991Mar14.012332.20774@massey.ac.nz> <1991Mar14.194554.12750@zoo.toronto.edu>
Sender: news@olivea.atc.olivetti.com
Organization: Olivetti ATC; Cupertino, CA
Lines: 28

In article <1991Mar14.194554.12750@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>My own philosophy on this one tends to be "if your system doesn't have
>enough resources in reserve to handle surges, then running news is a
>poor idea".

While I tend to agree in general I think there is merit in the two cases
mentioned.  In the case of being down, or having your incoming feed
down, the amount of news that can queue up can be as much as your feed
keeps.  The same thing can happen with recirculated old articles.  I
could, right now and very easily, put 362 Meg of old news onto the net.
Could your system handle that kind of "surge"?

>was getting away from scanning every article, which was intolerably slow
>even when traffic was an order of magnitude lower.  The only way to make
>this practical, really, would be to store the posting date centrally.
>I'd rather avoid revamping the history-file format *again*.

What is one more <magic character>668997597 in the history file among
friends? :-)

One idea I considered a while back was to force the articles modified
time stamp, using utimes(2), to be the posting date.  That would reduce
the cost to stat-ing the file instead of reading and parsing its
headers, and with no additional storage overhead.  It would also provide
for a fairly efficient method for news readers to sort the presentation
by posting date.

				Jerry Aguirre