Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!rpi.edu!tale From: tale@turing.cs.rpi.edu (David C Lawrence) Newsgroups: news.software.b Subject: Re: Cnews artnum in active file Message-ID: Date: 17 Aug 90 06:16:00 GMT References: <1990Aug16.185023.26200@squirrel.mh.nl> <1990Aug17.034849.17801@zoo.toronto.edu> Organization: Rensselaer Polytechnic Institute Computer Science, Troy NY Lines: 33 In article <1990Aug17.034849.17801@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: This is normal unless you have a crontab entry that occasionally runs upact (more portable) or updatemin (rather faster). Or optionally put it in doexpire so it is executed as soon as expire is. (The lower number is basically an inadequate kludge that smarter software should never look at, but there is a lot of dumb software in the world, sigh...) I agree; the lowest article scheme fails here due to Expires: sometimes making large holes in groups. I think I will review the latest NNTP protocol for a way to put in "this group has n articles in it" information in it after a readdir and check for S_IFREG files. This of course isn't terribly efficient, but is accurate right at the time of doing it. It's a real loser when trying to present a summary of groups and relative article volumes. The nice thing about the min field is it does give me a usually pretty close estimate of how many articles in the group, take the same amount of time to figure out no matter how huge the group is. Since I would rather have this information slightly wrong sometimes than not at all, I run updatemin. Unless I am missing something obvious, which could well be at the moment, I don't see a wonderful way which smart newsreaders could come up with that information without doing the costly operation above each time they wanted. 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. Right now, mthreads (for trn) daemon will only expire things from its database once a day. -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))