Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ucla-cs!sdcrdcf!lwall
From: lwall@sdcrdcf.UUCP (Larry Wall)
Newsgroups: news.software.b
Subject: Re: Is the history file really needed anymore?
Message-ID: <3791@sdcrdcf.UUCP>
Date: Thu, 15-Jan-87 15:58:52 EST
Article-I.D.: sdcrdcf.3791
Posted: Thu Jan 15 15:58:52 1987
Date-Received: Sat, 17-Jan-87 01:09:53 EST
References: <5504@ukma.ms.uky.csnet>
Reply-To: lwall@sdcrdcf.UUCP (Larry Wall)
Organization: Unisys - System Development Group, Santa Monica
Lines: 49

david@ukma.ms.uky.csnet (David Herron) proposes doing away with the history
file and using a master directory of article-i.d.s linked to the articles,
and says:
>   The Xrefs: header takes care of that right now ... the information
>   is in approximately the same format as in the history file.

Currently you don't have to open the article to get that info.  Of course,
you don't need the info unless you are actually going to delete the article.

>   hmmm ... offhand I'd say that the only program which would directly
>   use the master directory is expire and it should only be run once a day.
>   Further, expire could be written to be intelligent about the way
>   it runs through the directories.  (i.e. not a lot of random looking
>   about in the directory, but linear search ... )

You'd have to scan the entire directory every time you want to install an
article.  This is the killer.

>5) article id's are too long for non-flexname-in-the-file-system-people.
>
>   I'm tempted to just say "aaawwwww" but that's not fair.  Something
>   could be done like split it into a heirarchy of some sort...
>   (which would help in point 4 as well).

Add in the overhead of making new directories via a separate process part
of the time.  Add in the overhead of scanning periodically to eliminate
empty directories, though I suppose expire could do this easily enough.
Add in the hassle of making expire work recursively.

>6) we'd be able to get away from dbm...
>
>   it's a "yay" for xenix and sysv people ... they'd no longer be second
>   class citizens.  we'd also be able to get away from the hackery in
>   place to make sure the history file doesn't get corrupted by insertions
>   happening during an expire (etc).

You'd still have to be careful about insertions in the case of two rnewses
running simultaneously.  The link call probably provides sufficient locking
capability, but subdirectories would complicate matters.

>Are there any other issues?  Like I said, it's just random thinking.

Speaking of random thinking, eunice systems don't have linking.  You'd have
to emulate it, something like the LINKART code I threw into inews once upon a
time.  Eunice systems also tend to get slow when they have to think about
filenames that don't fit into the VMS filename straitjacket.

Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall