Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rutgers!mcdchg!heiby
From: heiby@mcdchg.chg.mcd.mot.com (Ron Heiby)
Newsgroups: news.software.b
Subject: history.dbm contents?
Message-ID: <62955@mcdchg.chg.mcd.mot.com>
Date: 13 May 91 23:32:57 GMT
Organization: Motorola Computer Group, Schaumburg, IL
Lines: 32

I've looked through the News 2.11 patch 19 source and believe I've
found every place where the history DBM file is referenced.  When an
article arrives on the system, the dbm file is queried to see if the
message-id already exists (case insensitive check).  If not, then the
article winds up getting installed on the system, a line is written to
the text history file, and an entry is made to the DBM history file
using the message-id as the key and the file offset into the text
history file of the line describing the article as the data.

While it might be really handy for some software that has a message-id
and wants to convert that to pathname(s) or such to have that info in
the DBM file that way, I can't find any software that actually makes
use of that information.  I've written a fairly complete expire Perl
script, which I'm about ready to start testing.  It occurs to me,
though, that if the actual *data* stored in the DBM file isn't used by
anyone, just the *key* (whether or not the key exists), then it
doesn't really matter whether that information is updated by expire.
If no one uses it, expire could simply delete keys for the ancient
articles and leave all the others untouched.  I would think that this
would make for a noticeable speed improvement.

Am I all wet, here?  Do I actually have to maintain that
correspondence between DBM and text forms of the history file?  If so,
why?  What software makes use of the data stored, rather than the fact
that some data exists?

BTW, has anyone done any speed comparisons between "good old" dbm and
GNU dbm?  It seems like on my system, the standard 2.11 expire.c runs
about three times slower if libgdbm.a (version 1.3) is linked in.
-- 
Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
"Wrong is wrong, even when it helps you." Popeye