Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!iuvax!watmath!looking!brad
From: brad@looking.on.ca (Brad Templeton)
Newsgroups: news.software.b
Subject: Re: Our friend, the GMT date.
Message-ID: <57592@looking.on.ca>
Date: 6 Dec 89 18:18:00 GMT
References: <4364@helios.ee.lbl.gov> <14810@well.UUCP> <1989Dec3.210413.27043@psuvax1.cs.psu.edu> <56239@looking.on.ca> <1989Dec5.142032.7706@talos.uucp> <1601@intercon.com> <1989Dec6.031329.13569@utzoo.uucp>
Organization: Looking Glass Software Ltd.
Lines: 42
Class: discussion

In article <1989Dec6.031329.13569@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>Be careful not to throw the baby out with the bathwater.  In the early days
>of C News, Geoff and I spent a lot of time mulling over alternate ways of
>organizing the database.  We finally concluded that there was no alternative
>we could think of that was worth the trouble.

Henry's probably right, although it's a close call.  The first reason you
might think of for switching is saving disk space.  Turns out you waste
only about 16% of your disk space on 1K blocking, so that isn't enough
reason to switch.  (Of course on 1 4K block system, it's different, the
wastage approaches 40%, I would guess.)

On non-unix systems without links, the problem is worse and you have to
find another route.  For DOS, with no links and 4K blocking, the current
method is right out.

Another improvement would be speed.  A system that allowed you to
index into long files need not even unpack batches.  'unbatching' could
be simply a matter of reading the pointers from the header of the file
and storing them in a table.  Process a meg of news in 5 seconds.
(Have to handle Path: specially, though.)

While this complicates the readers, it makes them faster.  If a person
reads news once a day, almost all the news will be in a small set of
files -- only a few dozen files to open and seek around in.

Expire is zippy, too.  Just drop the batches in the order they came in.


But on the whole, when you add the reader breaking issue, it isn't
worth it.

But you do have to *add* to the structure, as NN has done.  Of course,
NN's addition of a special program is a kludge, and the maintenance of
a database of subjects etc. is something the inews program should do.

Support for a database (more general tha NNs) has to go into NNTP soon,
or the future generation of readers won't work with it.

Such a database also applies to any signature searching.
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473