Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: news.software.b
Subject: Re: Is the history file really needed anymore?
Message-ID: <7529@utzoo.UUCP>
Date: Fri, 16-Jan-87 14:17:54 EST
Article-I.D.: utzoo.7529
Posted: Fri Jan 16 14:17:54 1987
Date-Received: Fri, 16-Jan-87 14:17:54 EST
References: <5504@ukma.ms.uky.csnet>, <1307@ncr-sd.UUCP>
Organization: U of Toronto Zoology
Lines: 40

> 3.  It would allow expire to be run with different values in different
>     newsgroups.  (It has always struck me as pretty silly that net.jokes
>     survives the same length of time as mod.sources.)

This has nothing to do with the format of the history file.  It is quite
possible to write an expire that does selective expiry with the current
history-file format.  It isn't even hard.  (The C news expire, which I
wrote, does it.)

Eliminating the history file is, on the whole, a silly idea.  Precisely
what benefits is the change supposed to produce?  If your news system
lets articles get filed without putting them in the history file, this
is a defect of the implementation, not the concept.  Ditto for foulups in
coordination between inews and expire.  (What makes you think that the
implementation of the new concept will be any better?  Of course, it won't
foul up in precisely the same way...)

Making expire dig out the inode of each file to decide whether to expire
it would be an awful performance disaster.  Expire wins very heavily indeed
from having a central, efficiently-scanned database of articles.

The assumption that article-ids always have reasonable formats is terribly
naive.  Have any of the people suggesting this done *systematic* *surveys*
of article-ids?  I thought not.  The vast majority of article-ids are in
simple and reasonable format; it's the not-insignificant minority that
aren't that causes trouble.  (I speak from experience.)

The *only* thing I've seen mentioned which is really a significant advantage
for this idea is eliminating the need to go through dbm (or not go through
it, on lobotomized Unixes like System V).  Not because there is anything
grossly wrong with dbm, but simply because it isn't universal and it is not
ideally portable in some ways.  The fix for this is to write a public-domain
dbm equivalent.  Assuming that Unix directories will do it for you at high
efficiency is, again, terribly naive.

Just what is the big win from throwing out the history file, as opposed to
fixing the bugs in the current handling of it?
-- 
Legalize			Henry Spencer @ U of Toronto Zoology
freedom!			{allegra,ihnp4,decvax,pyramid}!utzoo!henry