On Tue, 20 Mar 2001, Robert Feldt wrote:
> > The reality is that although many compression algorithms can work on
> > streams, that is, they only have to buffer a small, O(1) part of the file
> > at once. Some others (notably bzip2) want direct access to the whole file,
> > so if you could pipe data to it, it'd keep a O(n) buffer. This should
> > affect a lot the way you design the interface in the end.
> So maybe we need a distinction between StreamCompressor and
> BlockCompressor then?

Oh probably yes.

> Is there some common interface they share?

No.

And you can replace StreamCompressor by a plain object which you construct
by passing an IO-compliant object that must be read from, and an
IO-compliant object that must be written to.

And you can replace BlockCompressor by a plain object with a similar
constructor except 1st argument is a File to read from, specifically.

If there is a need for more flexibility, then you can just hack
something together (or even help me with IOMixin :-)

> Is this truning into an micro-increment, iterative, on-line
> DesignFest? :-)

Probably not. Micro-increments happen on large designs. This is a design
so small that almost any change to it is radical. And I just turned it
inside out.

matju