🚀 go-pugleaf

tale@turing.cs.rpi.edu (David C Lawrence) writes:
>                                             Of course, some things
>like trn and nn keep their own databases (boy, do I love all this
>space used on my disk) and run their own daemons, so they can keep an
>up-to-date cache of this information somewhere.

It is simply a trade-off between *your* time and the extra (few %) disk
space and cpu-time.

moraes@cs.toronto.edu (Mark Moraes) writes:
>And they usually have a hard time dealing with the holes left with
>cancels, supersedes, etc...

I does not have to be a (big) problem if the database is "expired"
often enough.  At least for a local news source, this is quite efficient
with nn release 6.4 (it is *not* efficient with nntp  I admit).

>It would be really nice if the trn, nn and nntp people could get
>together and agree on a standard database that all three could use.
>Maybe even a single daemon that could be asked the right questions.

Sure, that would be *very* nice.  But in that case, I would say that
it is really the task of the news transport to maintain the database
(i.e. if a unified database for all news readers can be agreed on
 - and we write an RFC for it - then I see no reason to have separate
daemons maintaining it).

But then there is the problem whether we can really agree on a common
format - I'm not sure since it is very nice to have the freedom to
be able to add new information to the database as it becomes necessary
to support new features; having an RFC specifying a fixed format would
certainly limit future developments of nn unless we can find a sufficiently
flexible format allowing news reader specific extensions; but then you
still need the news reader specific daemon to maintain it.

But I am certainly willing to give it a try!

-- 
Kim F. Storm  <storm@texas.dk>		No news is good news,
Texas Instruments A/S, Denmark		  but nn is better!