Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!psuvax1!shire!flee
From: flee@shire (Felix Lee)
Newsgroups: news.software.b
Subject: Re: Reliable news batches, anyone?
Message-ID: <4392@psuvax1.cs.psu.edu>
Date: 21 Mar 89 15:09:32 GMT
References: <4387@psuvax1.cs.psu.edu> <1989Mar20.190304.23059@utzoo.uucp>
Sender: news@psuvax1.cs.psu.edu
Reply-To: flee@shire.cs.psu.edu (Felix Lee)
Organization: Penn State University Computer Science
Lines: 25

In article <1989Mar20.190304.23059@utzoo.uucp>,
  henry@utzoo.uucp (Henry Spencer) writes:
> If your transmission path does not give you byte-for-byte fidelity,
> regardless of line lengths etc., what you need is some sort of encoding
> scheme to get the data through intact.  Fault-tolerance in the batch
> format is only a band-aid -- the articles are getting mangled!

We regularly exchange news with an IBM VM/CMS machine over a RSCS
link.  "Byte-for-byte fidelity" loses something in translation
(e.g., tabs get expanded to spaces).

Most news articles are plain text; these manglings have little effect
on the content of the article.%  Why eat up CPU cycles encoding text,
decoding it, reliably unbatching it, and then mangling it, when a
simple band-aid can let you unbatch it reliably in the first place?

A news batch without byte counts would let nntpd blast incoming
news to rnews, without needing to fork off a new rnews for each
article, without needing to save the article to figure out the
byte count before batching it to rnews.

% One exception is detabified Makefiles, which many versions of
make dislike.
--
Felix Lee	flee@shire.cs.psu.edu	*!psuvax1!shire!flee