Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.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: Reply to Jones's criticism of standard.
Message-ID: <19700.Jun2120.54.2091@kramden.acf.nyu.edu>
Date: 21 Jun 91 20:54:20 GMT
References: <861@spam.ua.oz>
Organization: IR
Lines: 23

In article <861@spam.ua.oz> ross@spam.ua.oz.au (Ross Williams) writes:
> However there are two very strong arguments for the block interface:
>    EFFICIENCY: A stream interface requires one procedure call per byte
>    processed.  For high speed applications this is unacceptable.

Huh? UNIX's read() is a stream interface, and it sure doesn't require
one procedure call per byte processed.

>    DIRECTNESS: A stream interface will force many algorithms to become
>    involved in unnecessary buffering.

Your block interface forces *all* algorithms to become involved in
unnecessary blocking. Again it sounds like you're concentrating on
zero-delay modem compression. I don't think compressors should be forced
into that model.

> In contrast, a stream interface  can always be efficiently constructed
> over the top  of a block interface.

This is not true, especially given your requirement that the block
compressor be memoryless.

---Dan