Path: utzoo!attcan!uunet!husc6!rutgers!att!icus!dasys1!tneff
From: tneff@dasys1.UUCP (Tom Neff)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: SIMTEL20 to ban ARC files
Keywords: lzw, atob/btoa, 7 bit pure
Message-ID: <6583@dasys1.UUCP>
Date: 22 Sep 88 13:52:30 GMT
References:   <6630@ihlpl.ATT.COM> <2736@uoregon.uoregon.edu> <8475@smoke.ARPA> <2594@csccat.UUCP> <424@pigs.UUCP>
Reply-To: tneff@dasys1.UUCP (Tom Neff)
Organization: Independent Users Guild
Lines: 40

In article <424@pigs.UUCP> haugj@pigs.UUCP (John F. Haugh II) writes:
>i'd like to see an ARC tool which did NO compression and then have
>another tool which did the compression and then yet another for the
>decompression.  that would yield three small tools, each of which
>could be highly specialized.

This is somewhat reminscent of the old order-of-operations quandary
in the days of LBR and SQ on CP/M and MSDOS.  There you had two separate
tools, a squeezer and a librarian.  There were two headaches.  First,
people kept LBR'ing *first* and then squeezing (yielding an LQR file),
which is the wrong way to do it for two well-defined reasons[1].
Second, it was an unnecessarily complicated business managing archives
with so many processing steps and intermediate files.  People tried to
work up batch files to automate the process, but they were not reliable
or portable in general.

One of the things ARC (in any form) really brought to the party was
unparallelled user convenience -- combining the steps invisibly and
selecting an algorithm automatically were godsends.  There was a
certain size and performance tradeoff but it was well worth it for
almost all users.

Small, specialized tools are great too of course, which is why Buerg
wrote the little ASM one-shot extractors and builders.

--------------------------

NOTES

[1] Squeezed libraries are much worse than libraries of individually
squeezed members because (a) an LQR has no immediately accessible
directory structure - it has to be unsqueezed before you can look at
it; and (b) dissimilar member files (README, executable, fonts etc)
yield a heterogeneous library which responds poorly to most types
of compression.

-- 
Tom Neff			UUCP: ...!cmcl2!phri!dasys1!tneff
	"None of your toys	CIS: 76556,2536	       MCI: TNEFF
	 will function..."	GEnie: TOMNEFF	       BIX: t.neff (no kidding)