Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!owl!madler
From: madler@owl.caltech.edu (Mark Adler)
Newsgroups: comp.sys.handhelds
Subject: Re: Why ASC over UUENCODE?
Message-ID: <1991Feb16.191721.23352@nntp-server.caltech.edu>
Date: 16 Feb 91 19:17:21 GMT
References: <20148@shlump.nac.dec.com> <1991Feb14.015132.10732@nntp-server.calt <27bc3211:2035.6comp.sys.handhelds;1@hpcvbbs.UUCP>
Sender: news@nntp-server.caltech.edu
Organization: California Institute of Technology, Pasadena
Lines: 72
Nntp-Posting-Host: owl


Andrey Dolgachev suggests:

>> Look, Mark, chill.  Use ASC, trust me.

Well, I *do* use ASC, and I'm rather glad Bill Wickes wrote it and gave it
to us out of the kindness of his heart.  If I really cared about the issue,
I'd write a uu-format version of ASC and let natural selection take its
course.  In all truth, I just like to argue sometimes.

I get the impression that most people think ASC is just fine, so I won't
try to convince anyone anymore with my steel-clad logic.  However, in the
pursuit of the pleasure of debate, I will answer Andrey's points.  Those
bored with the whole thing can junk this message now ...

>> 1)  ... UU is not in place everwhere, and it's a pain to put into place.
>> 2)  ASC is available for the one machine which it needs: the 48. ...
>> 4)  ASC is useful for other things, like Internals programming. ...
>> 6)  ASC is here.  Almost everyone has it on the 48.

The issue, as I see it, is simply: "Why doesn't ASC use a UU-compatible
format?"  In other words, I'm imagining a near future in which there are
two versions of ASC, the current one, and one that is compatible with the
uu-format.  Which one is better?  Obviously ASC is better if it's the only
thing available, as is the case presently (point 6 above).

In that light, I would answer 1) ASC is in place nearly nowhere, 2) The
uu-ASC is also on the 48 (remember, we're in this hypothetical future), and
4) The old ASC is still there for you to use as a poor substitute for a hex
editor on the HP.

I should add here that I concede Andrey's point that uuencode/decode is not
as widely available as I implied.  However, it is no harder to get uuencode
to work on the Mac than ASC is, and I'd lay fairly good odds that someone has
uu* on the Mac already.

>> 5)  I don't care about bandwith, it's not that much of a difference.

Well, I have to admit that I don't care that much about it either.  After all,
I don't pay for it.  That was a pretty weak argument on my part.  However, I
think you *will* care when people get HP-48 compilers working, and you find
it taking forever to get the object code into the HP, and then failing because
there's not enough memory left to make the object.  Then that 50% will start
to seem significant.  On the other hand, the way I do it is to always use
binary in and out of the calculator for such things, and that is where ASC is
lacking, since most people don't have an ASC on their machine.  The same
arguments apply about not having C compilers that was used against UU*--but
there are object versions of UU* out there for PC's, and I suspect Macs as
well.  And it's always there on Unix machines.

>> 3)  With ASC, I can tell if it messus up by looking at what it got.  With
>>     UU, I can't, it's all gibberish to me anyways.

I know I wouldn't be able to spot a missing line in the ASC *or* UU format.
If Andrey can, he's a better man than I.  However, the UU format is just as
structured as ASC's, if not more so (lines start with an "M", there's a
begin at the beginning and an end at end).  Anyway, what's relevant is whether
the resulting object is faithful after it has been mangled by kermit, ftp,
uu*, asc, what have you.  This brings up a point that Andrey *didn't* mention,
which is, in my opinion, the strongest argument against the uu-format.

ASC has a CRC check.

My response is that I consider ASC's crc check a welcome, additional error
check in a long line of error checking done by ftp, kermit, internet, etc.
But, I would like to urge everyone to *always* include the result of BYTES on
an object that you post, whether it is in ASC form, ASCII upload form, or
typed in, and whether the object is a user program or in RPL/machine code.
Then, the lack of a crc in the uu-format is not a problem.

Mark Adler
madler@pooh.caltech