Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!ukc!axion!tharr!gtoal
From: gtoal@tharr.UUCP (Graham Toal)
Newsgroups: comp.compression
Subject: Re: Reply to Dan Bernstein's criticisms of standard.
Message-ID: <2241@tharr.UUCP>
Date: 23 Jun 91 16:22:03 GMT
References: <4496@optima.cs.arizona.edu> <3406.Jun2302.12.0491@kramden.acf.nyu.edu>
Reply-To: gtoal@tharr.UUCP (Graham Toal)
Organization: Public Usenet Access
Lines: 47

In article <3406.Jun2302.12.0491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
:Exactly. I imagine modem manufacturers would love this standard, for
:example, while UNIX users and programmers would love a program-based
:standard. Here's a challenge, Ross: Rewrite compress to conform to your
:standard. If you can do that, publish it and explain why it's useful.
:I'm always wary of ``standards'' that haven't been given at least two
:unrelated implementations.
:
:> I'd also like to repeat someone else's suggestion of seperating the
:> compression procedure and decompression procedure.
:
:Ditto.

That's exactly what I was trying to say when I referred rather tactlessly
(apologies, Ross) to 'pretentious twaddle'.  Imposed standards just don't
work.  Go ahead and implement the ideas you're suggesting, publish them
in source form on the net, and let the market decide.  I've a *lot* of
time for Dan because instead of moaning about compress, he went out and
implemented something that works.  (Whether it will replace compress is
something I'm sitting back and hopefully watching for...)

Incidentally, I've implemented something much like you describe.  For it
to be portable, you have to (yuk - I do it but I hate it) mandate that
none of the data structures used by compression or decompression are
larger than 32k bytes, even if this reduces the compression you get.

And seperating out compression and decompression procs is worthwhile.

The biggest thing a standard could do for portability is this:
   1) Define the file format as a series of blocks; each block can
      be compressed with an arbitrary algorithm to a fixed interface.
   2) Define the procedure interface exactly (eg decomp(inblock,outblock,
         insize, outsize) -> status) and arrange for the encompassing
      compressed file TO INCLUDE THIS C CODE so that any decoder can
      extract it, link it in, and use it to extract the data.

This might seem a stupid suggestion but it's the only one I can
think of which will allow backwards and forwards compatibility.  otherwise
you get into the pkzip thing of rushing around tracking newer versions
of algorithms and having decompression programs with twenty different
algorithms built in.

Graham
PS Ross, I probably wouldn't have shot from the lip in that last post
if you'd titled it 'request for comments' or even 'draft standard'...
-- 
(* Posted from tharr.uucp - Public Access Unix - +44 (234) 841503 *)