Xref: utzoo alt.sources.d:646 comp.sources.d:5589
Path: utzoo!attcan!uunet!shelby!unix!Teknowledge.COM!uw-beaver!zephyr.ens.tek.com!tektronix!psueea!eecs!kirkenda
From: kirkenda@eecs.cs.pdx.edu (Steve Kirkendall)
Newsgroups: alt.sources.d,comp.sources.d
Subject: Re: Unnecessary tar-compress-uuencodes
Message-ID: <3124@psueea.UUCP>
Date: 12 Jul 90 18:12:55 GMT
References: <15652@bfmny0.BFM.COM> <3114@psueea.UUCP> <1990Jul10.203015.27282@eci386.uucp> <5256@plains.UUCP>
Sender: news@psueea.UUCP
Reply-To: kirkenda@eecs.UUCP (Steve Kirkendall)
Organization: Portland State University, Portland, OR
Lines: 60

In article <5256@plains.UUCP> overby@plains.UUCP (Glen Overby) writes:
>In article <15652@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) charges:
>>We have recently seen a spate of "source" postings in "uuencoded
>>compressed TAR" form, instead of SHAR or other traditional plain text
>>formats.
>
>Every time someone posts a source file which is not uuencoded, they get
>flamed by a dozen BITNauts who feel ripped off for not having gotten a good
>copy.
>
>
>I offer one sugestion: for groups which are source-only, have the gateway
>program pump everything thru 'compress | uuencode' before feeding it to
>Listserv.  I still see no solution for discussion groups which also get
>sources posted to them.
>
>Other Solutions, anyone?

Here's an idea: Lets compromise!  Come up with a format that really works!

We should be able to come up with a protocol that combines the safety of
uuencoding with the readability of shar archives.  Some features I would
like to see in the ultimate USENET archive format are:

1) The archive should be plain-text.  That is, each text file in the archive
   should be easy to locate within the archive, and it should be readable
   without the need to extract it.

2) The format would only be used to combine several text files into a single
   text file.  If you really must include a non-text file, then uuencode
   that one file.

3) Archives should begin with a table of all printable ASCII characters,
   so we can tell when transliteration has gone awry.

4) The archive program should split long lines when the archive is created,
   and rejoin them during extraction.

5) Tabs should be expanded to spaces.  The extraction program should convert
   groups of spaces back into tabs.

6) The program that creates the archive should give a warning message when
   a file's whitespace is likely to be reformated.  For example, spaces at
   the end of a line are a no-no.

7) The extraction program should be clever enough to ignore news headers and
   other introductory text, just for the sake of convenience.

8) It should be possible to embed one archive inside another.  This ability
   probably wouldn't see much use, but lack of the ability could sure be a
   nasty surprise to somebody.  "What?  You mean it only works on *some*
   text files?"

9) Should we use trigraphs for some of the more troublesome ASCII characters?
   The extraction utility could convert them back into real characters.

Did I miss anything?  Did I get anything wrong?  Does anybody know of an
existing format that comes close to these specs?
-------------------------------------------------------------------------------
Steve Kirkendall    kirkenda@cs.pdx.edu    uunet!tektronix!psueea!eecs!kirkenda