flee@shire.cs.psu.edu (Felix Lee) (03/19/89)
How about a news batch format that doesn't depend on something as system-dependent as character count? If a news batch is sent over a link that truncates long lines (like Path: or References:), then part of the #!rnews line for the next article gets eaten. (Ever wonder about "linecount expected 24, got 23"?) Unbatching resynchs itself, but you lose that article. And sending a batch over a mail link that changes '\n' to CR-LF, you have to compensate for an extra character each line. Something like internet-style dot-terminated articles, maybe. The disadvantage is slower processing.. (unless you're going to do line munging anyway) (and resynchronizing is almost as slow) -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
henry@utzoo.uucp (Henry Spencer) (03/21/89)
In article <4387@psuvax1.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >How about a news batch format that doesn't depend on something as >system-dependent as character count? If a news batch is sent over a >link that truncates long lines (like Path: or References:), then part >of the #!rnews line for the next article gets eaten... >... And sending a batch over a mail link that >changes '\n' to CR-LF, you have to compensate for an extra character >each line. 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! The right solution is to do whatever is necessary (uuencode, btoa, etc.) to get the data through intact. Once you have done that, the unbatcher resync problem disappears. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
david@ms.uky.edu (David Herron -- One of the vertebrae) (03/21/89)
The solution -- in the grand tradition of BITNET -- BNNTP.
Those of you who know and love BSMTP will immediately know what I mean.
--
<-- David Herron; an MMDF guy <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- The problem with mnemonics is they mean different things to different people.flee@shire (Felix Lee) (03/21/89)
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