Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!ox.com!yale.edu!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.compression
Subject: Re: Justification of proposed interface standard.
Message-ID: <19428.Jun2120.43.3891@kramden.acf.nyu.edu>
Date: 21 Jun 91 20:43:38 GMT
References: <860@spam.ua.oz>
Organization: IR
Lines: 24

In article <860@spam.ua.oz> ross@spam.ua.oz.au (Ross Williams) writes:
> If the standard were to provide  parameters in the interface which the
> user  program could  use to  dial  up various  versions of  particular
> algorithms, the  parameters provided  in the  interface would  vary in
> their semantic meaning from algorithm to algorithm.
> To resolve  this mess, the  standard prohibits parameters.  This means
> that generic algorithms that have parameters must be instantiated with
> specific static parameter values before  they can be standardized. The
> standard also forces the algorithm designer to specify how much memory
> the algorithm will require.

I find this completely unrealistic.

Ross, it sounds like you're trying to specify a standard for modem
(i.e., zero-delay) compression. But most compression in the real world
is high-delay. In fact, someone compressing data for an archive, or for
news batching, is much better off with control over the parameters. That
way he can adjust them to fit his needs without swapping in an entirely
different ``standard'' routine. He doesn't want to make the blocking
explicit, or to deal with the oodles of information you've defined; he
just wants to get a file or a bunch of files compressed as efficiently
and effectively as possible.

---Dan