Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!brazeau.ucs.ualberta.ca!unixg.ubc.ca!ubc-cs!uw-beaver!zephyr.ens.tek.com!uunet!decwrl!mejac!orchard.la.locus.com!devnet.la.locus.com!richard From: richard@locus.com (Richard M. Mathews) Newsgroups: news.software.b Subject: Re: Suggested Improvements to C News Error Handling Message-ID: <1991Jun28.035024.1202827@locus.com> Date: 28 Jun 91 03:50:24 GMT References: Organization: Locus Computing Corporation, Los Angeles, California Lines: 45 mathew@mantis-consultants.co.uk (mathew) writes: >REFINEMENT #3: Add a history file for errors. >--------------------------------------------- >5.7. At the end of each week: >5.7.1. Go through the error history file. For each site mentioned, take the > alphanumerically first Message-ID out of all those logged, and use it > to produce a new Message-ID by replacing the first "<" with "5.7.2. Write an article with the new message-ID to news.errors, containing a > summary of all the errors recorded as a result of that site. >This modification helps to reduce the number of error reports when there is a >large barf of old *corrupted* news. Overall, I like the whole proposal. I am a bit skeptical, however, about how much this refinement will really reduce the bandwidth used up by the error messages. The message with the alphanumerically first Message-ID for this week will not be the same on all machines, because the set of machines which arrived THIS week will be different in different places. Many different messages with "low" Message-IDs will get chosen by different systems. Furthermore, once a week is a pretty low reporting rate. Many of us don't have the luxury of keeping more than a few days of news in our spools. An error report a week later doesn't help us track down problems at all, nor does it allow us to repost the corrected version of the article. Unfortunately, if you increase the frequency or reporting, then you start getting pretty close to reporting 100% of all of the errors. And since your summaries of all bad articles might be bigger than each detailed message reporting each particular bad article (not to mention less useful since you need to know what the mangled header looked like where it was rejected), you might end up using up just as much bandwidth. I do like the idea of using a scan through the log to generate the error reports. As Henry points out, this means relaynews doesn't have to take any time dealing with this at all. But I would report every error, and I would do so within 24 hours of detecting the error. Richard M. Mathews Lietuva laisva = Free Lithuania richard@locus.com Brivu Latviju = Free Latvia lcc!richard@seas.ucla.edu Eesti vabaks = Free Estonia ...!{uunet|ucla-se|turnkey}!lcc!richard