jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) (06/21/91)
From article <859@spam.ua.oz>, by ross@spam.ua.oz.au (Ross Williams): > DATA COMPRESSION INTERFACE STANDARD > =================================== > 2.2.1 A conforming procedure must have a parameter list that conveys > no more and no less information than that conveyed by the following > "model" parameter list. > IN action - The action requested of the data compression procedure. > INOUT memory - A block of memory for use by the algorithm. > IN fresh - Is this the start of a new context block? > IN inblock - An array of input bytes. > OUT outblock - An array of output bytes. > OUT identity - Record specifying attributes of the algorithm. The idea of passing the desired action to one omnibus routine that can both compress, expand, and perhaps wash cars is odious. It means that the entire baggage of compression must be included for applications which only decompress, and vis a versa. I have yet to see any non-artificially constructed examples where I would want to use either the compress or expand operations at the same point in a program, depending on some variable. Thus, it would seem quite practical to use two separate procedures, one for compressing a block, and one for expanding an already compressed block. Doug Jones jones@cs.uiowa.edu ------------ Spam! Remember, it's not just for breakfast anymore!