Xref: utzoo alt.sources.d:607 comp.sources.d:5554
Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!bu.edu!orc!inews!iwarp.intel.com!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: <3114@psueea.UUCP>
Date: 9 Jul 90 17:41:17 GMT
References: <15652@bfmny0.BFM.COM>
Sender: news@psueea.UUCP
Reply-To: kirkenda@eecs.UUCP (Steve Kirkendall)
Organization: Portland State University, Portland, OR
Lines: 68

Some text has been edited out of the following quotes...

In article <15652@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes:
>We have recently seen a spate of "source" postings in "uuencoded
>compressed TAR" form, instead of SHAR or other traditional plain text
>formats.

I'm certainly guilty of posting articles in *.tar.Z.uue format.  I'm not
entirely happy with it, but I believe there are some valid reasons for
using this ugly format...

> * Readers can no longer easily inspect the source postings BEFORE 
>   installation, to see if they merit further interest.

A valid gripe.  I agree with you 100% on this one; it is the main reason
I'm not entirely pleased with uuencoding.

I always describe the contents of a uuencoded article, in a plain-text
paragraph before the "begin" line of the uuencoded stuff.  I try to
make this description sufficient to allow reeaders to decide whether or
not the article worth keeping.

> * Compressed newsfeeds, which already impart whatever transmission
>   efficiency gain LZW can offer, are circumvented and in fact
>   sandbagged by the pre-compression of data.

So sites with compressed newsfeeds don't care a whole lot, but those with
uncompressed feeds DO care.  Any sites with little free disk space also benefit
from the compression.

> * Crucial source format conversions such as CR/LF replacement, fixed
>   or variable record encoding, ASCII/EBCDIC translation, etc, which
>   automatically take place in plain text news/notes postings, are
>   again circumvented; users in alien environments are left with
>   raw UNIX format bitstreams to deal with.

But I don't want the network to translate my articles!  When I post an article,
there's a good chance that it will go from a UNIX machine, through BITNET, to
another UNIX machine.  Because it went through BITNET, it will have been
translated from ASCII into EBCDIC and back into ASCII.  This translation may
leave scars: some characters may have been transliterated incorrectly, long
lines may be silently truncated or split, and whitespace may be changed.  And
all of this is happenning on machines that I have no control over!

When I transmit a file, I want it to be received unchanged.  If it must be
translated to suit the receiver's environment, then that translation should
be done explicitly by the reciever, not magically by some machine halfway
between here & there.

> * The format presupposes the existence of decoding tools which may
>   or may not be present in a given environment.

They should be.  People have been posting them, and they're available at
archive sites.

Certainly, when I post an article, I do so because I want to make my source
code available to people.  Anything that limits the availability should be
viewed with a critical eye.  Uudecode and compress fall into that catagory.
So does the BITNET protocol.  A user who lacks uuencode and compress can get
them from somewhere.  A user who has only a BITNET feed is stuck.

If there was no such thing as BITNET then I would probably use shar.

>Psychoanalysis is the mental illness   \\\    Tom Neff
>it purports to cure. -- Karl Kraus      \\\   tneff@bfmn0.BFM.COM

-------------------------------------------------------------------------------
Steve Kirkendall    kirkenda@cs.pdx.edu    uunet!tektronix!psueea!eecs!kirkenda