Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!mcvax!ukc!dcl-cs!bath63!pes
From: pes@bath63.UUCP (Paul Smee)
Newsgroups: net.micro,net.micro.atari16
Subject: Re: New way to post binaries
Message-ID: <250@bath63.UUCP>
Date: Fri, 31-Oct-86 11:40:08 EST
Article-I.D.: bath63.250
Posted: Fri Oct 31 11:40:08 1986
Date-Received: Wed, 5-Nov-86 06:14:59 EST
References: <2035@dalcs.UUCP> <2462@gitpyr.gatech.EDU>
Reply-To: pes@ux63.bath.ac.uk (Paul Smee)
Distribution: net
Organization: AUCC c/o University of Bath
Lines: 20
Xref: watmath net.micro:15868 net.micro.atari16:2946


I'd agree with Ken Thompson.  uuencode may not be great, but it is usable --
sometimes with a little thought using inspiration derivable from the
uuencode doc.  And, it is more-or-less standardly available on Unix systems.
If we invent a new encode decode technique, I foresee continual requests from
new people joining the net for yet-another retransmission of fredcode -- or
whatever it's called.

From this standpoint, even hex encoding is optimal, as it is obvious when
you see a hex file what you should do to unpack it.  I fear new baroque
and clever coding techniques will cause more confusion than they solve.
(Unless, of course, you can manage to get the new stuff packaged in as a
standard bit of Unix systems.)

(Also, a quick comment on the original version of the proposal --
The character set A-P is only contiguous on ASCII machines.  Fine for
my purposes, but not that handy for EBCDIC users.  Of course, I've been
known to argue that EBCDIC users deserve whatever they get, but I'm
prepared to accept that others might disagree; and besides, it's not clear
there *is* any nice subset of chars in EBCDIC.)