From mboxrd@z Thu Jan  1 00:00:00 1970
From: lm@mcvoy.com (Larry McVoy)
Date: Wed, 16 Jul 2014 07:30:39 -0700
Subject: [TUHS] the sin of buffering [offshoot of excise process from a
 pipeline]
In-Reply-To: <20140716060358.GP10065@mercury.ccil.org>
References: <201407152343.s6FNhnUT001960@coolidge.cs.dartmouth.edu>
 <20140716003220.GA24974@mcvoy.com>
 <20140716035303.GO10065@mercury.ccil.org>
 <20140716040509.GA27375@mcvoy.com>
 <20140716060358.GP10065@mercury.ccil.org>
Message-ID: <20140716143039.GA31888@mcvoy.com>

On Wed, Jul 16, 2014 at 02:03:58AM -0400, John Cowan wrote:
> Larry McVoy scripsit:
> 
> > We tried that but the problem is that you can't encode all the options you
> > want in just a character.  Compression doesn't take options, the CRC/XOR
> > layer wants to know how big you might think the file is (because we 
> > support blocksizes from about 256B to 256K and we want to know the 
> > file size to guess the block size).
> 
> It's a string: you can have as many characters as you want.

I understand your desire to have one API.  We tried and it just wasn't
practical.  Imagine pushing an encryption layer that wants a key,
XOR layer that wants block size, etc.