Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!ur-tut!sunybcs!boulder!hao!ames!ucbcad!ucbvax!hoptoad!gnu
From: gnu@hoptoad.UUCP
Newsgroups: news.software.b
Subject: Re: Messages with >80-character lines
Message-ID: <3269@hoptoad.uucp>
Date: Wed, 28-Oct-87 00:39:02 EST
Article-I.D.: hoptoad.3269
Posted: Wed Oct 28 00:39:02 1987
Date-Received: Sat, 31-Oct-87 01:03:35 EST
References: <767@quacky.UUCP> <696@unisoft.UUCP> <37e7ff5a.b8ab@apollo.uucp> <835@quacky.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 60

My take on the problem is that there are two problems here.  One is the
display problem, "how does it look on the screen"?  The other is the
fixed-record-format-system problem, "why did my system truncate it"?

The display problem can be fixed by anybody at local option.  The guy
who wanted a TeX based news reader can have one.  Ditto people with 40
column terminals who want word wrap.  Write it yourself.  This is how
the current netnews software got built, by people who wrote what they
wanted to run.

The fixed record format problem is also a local problem.  Sites that
can't send, receive, and pass-thru arbitrary text or binary data have a
problem.  I don't think we should toss our nice flexible systems just
because they have a problem.  I think they should add some flex, and if
they aren't interested in flexing, to hell with 'em.  This is not a
network of keypunches.

Note that the fixed record problem actually has two subproblems.  One
is file systems that require fixed records.  There are actually very
few of those; most systems with "file types" also allow variable length
records if the programmer asks for them.  Yesterday I proposed that
somebody implement an IBM OS access method for ascii datasets with
newlines.  It is probably the easiest access method you'll ever write.
Any volunteers?

The second subproblem is networks that require fixed records.  RSCS may
be one, since it was designed for card readers and printers on the
other end of a 1200 baud line.  In that case, a simple transformation
can be done at both ends.  compress|btoa is not a bad idea.  If it
doesn't run on your IBM mainframe, well, get a C compiler, or
reimplement it in PL/1, or quit complaining about truncated records.
Not to mention that RSCS will need to be junked sometime in the next 20
years; you could make sure whatever your site replaces it with can
handle arbitrary binary or ascii data.

Comments on a specific proposal:  dce@mips.UUCP (David Elliott) wrote:
> 	Warning: This article contains lines longer than 80 characters,
> 	         making it difficult for some people to read. The
> 		 articles has been sent, but you should refrain from
> 		 doing this in the future.

This is a horrible idea.  We already have every new user posting their
messages twice because "it left my signature off the first time".  They
will do the same thing with "my lines were too long the first time, here
is the fixed version".  If it complains, it shouldn't post the message;
if it posts the message, it shouldn't complain.  If after a complaint,
they insist on sending it anyway, it can let the message through,
like the passwd command.

> Yet another idea might be to add a Max-Line-Length: header field,
> generated by inews for articles with lines longer than 80 (again,
> chosen arbitrarily, and I would even suggest 40 in this case).

This information is already available if the news software wants it --
it can just count the lengths of the lines.  Let's NOT add another useless
header line.
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
Love your country but never trust its government.
		      -- from a hand-painted road sign in central Pennsylvania