Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry F Aguirre)
Newsgroups: news.software.b
Subject: Re: Is the history file really needed anymore?
Message-ID: <386@oliveb.UUCP>
Date: Thu, 15-Jan-87 20:10:16 EST
Article-I.D.: oliveb.386
Posted: Thu Jan 15 20:10:16 1987
Date-Received: Fri, 16-Jan-87 04:03:32 EST
References: <5504@ukma.ms.uky.csnet>
Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 43

Regarding eliminating the news/history file:

I think this is a great idea.  The idea of a separate history and news
data base always introduces the problem having the two disagree.
Besides, the history file, even with the DBM copy, is not a very
efficient way to access articles.  Even the common problem of trying to
find an article from its article ID is inefficient.

The directory search and length problems are no different than those
introduced by the news group names.  Comp.os.unix gets mapped to
comp/os/unix, changing the dots to directory levels.  For article IDs I
think something useful could be done with this like mapping:

		<5504@ukma.ms.uky.csnet>
to:
		csnet/uky/ms/ukma/5504

This has the advantage of grouping all articles posted by a given site
in the same directory.  The only problem with a scheme like this is that
it places a more restrictions on the format of the ID.  Written
correctly the software could provide for some less restrictive format
when it ran into a nonstandard ID.  (I have never seen any IDs not in
the above format.)

To cancel an article mearly map the ID to a pathname and create a zero
length file.  This will hold the article ID while eliminating the data
portion of the article.

Eliminating the history file does force expire to do more work.  Perhaps
another link could be created for each article based on when it is
supposed to be expired.  A directory like "expire_date/17" could hold a
link to all articles that are due to expire on the 17th of the month.
In this case almost every article expire read would be one it would have
to remove anyway.  Expire could then use the "Xref:" line to track down
all links to each article and remove them.

This scheme would not be perfect, but then again neither is the current
one.  Every so often I have to track down articles that are not in the
history and therefor don't get expired.  Please don't tell me about the
nohistory/rebuild options to expire.  They violate all the advantages of
the history file and don't correctly handle corrupted articles.

					Jerry Aguirre