On Mon, 19 Mar 2001, Dennis Decker Jensen wrote:
> Robert Feldt wrote:
> > BTW, maybe we should agree on a base class for compression algorithms so
> > that we can start collecting them into a lib? Anyone got a sensible
> > OO design for compression?
> Don't know anything about compression algorithms, but the design smells like
> a Strategy Pattern (variation of algorithms used in an object with a common
> interface - also known as changing class at runtime) or some sort of
> degenerate Bridge Pattern (separation of interface and implementation).

So what is that jargon applied to Ruby? "Oh I guess we'll have to use...
classes! ... hum, and polymorphism too!"

Here's a first attempt to something precise:

	A Compressor includes the module CompressorInterface. Construction
	is done with .new with one argument called "target", an object
	which supports #write. Configuration of impl-dependent options is
	done by, um, impl-dependent means.  Data is written using
	#write(data) which is used like IO's. That method compresses as
	much data as it can and calls target.write.

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.

matju