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