Path: utzoo!mnetor!uunet!mcrware!jejones
From: jejones@mcrware.UUCP (James Jones)
Newsgroups: comp.sources.d
Subject: Re: Standard for file transmission
Message-ID: <699@mcrware.UUCP>
Date: 6 May 88 12:31:59 GMT
References: <292@cullsj.UUCP> <55@psuhcx.psu.edu> <537@csccat.UUCP> <8430@iuvax.cs.indiana.edu>
Organization: Microware Systems Corp., Des Moines, Ia.
Lines: 21
Keywords: protocol compression source
Summary: software tools vs. monolithic programs

In article <8430@iuvax.cs.indiana.edu>, bobmon@iuvax.cs.indiana.edu (RAMontante) writes:
> [Compress's] Unix-origin philosophy says that separate functions should be
> done by separate routines with their outputs tied together by the operating
> system....The philosophy works fine on a big multitasking machine like a VAX
> (or a suitably equipped 680x0 or '386?)...
> This piece-at-a-time philosophy is weaker on something like my MSDOS 8088 box.
> ...In such a situation an integrated package (viz., zoo or arc) makes a lot
> more sense.

Oddly enough, I would make just the opposite argument, though it is, like Mr.
Montante's, influenced by the particulars of my home system, which has memory
limitations too.  A monolithic glob like ARC, which includes every compres-
sion method known to man (well, arithmetic compression evidently hasn't made
it in yet, and PKARC has LZ with a knob tweaked), won't fit on my 6809, which
limits me to 64K (code + data) per process under OS-9/6809 Level Two.  If those
compression programs were written separately, they could individually fit and
could be invoked by a process that knows the surrounding header bilge and
calls up the appropriate compress/decompress program.  (The software tools
philosophy has advantages for programs as well as users.)

		James Jones