Re: The Byterange filter -- a new design -- feel free to rip it to shreds

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Tuesday, July 13, 2004 11:21 AM -0500 "William A. Rowe, Jr." 
<wr...@rowe-clan.net> wrote:

> Body/content generation or transformation should not be contending with
> these issues you raised above.  It's not unreasonable to expect some
> metadata to pass through or be transformed (such as a content length,
> which some filter can tweak or discard altogether.)  But it is getting very
> obscure to expect them to contend with byteranges.  What's next?

Agreed.

> That's why I proposed a skip-forward semantic to support byte ranges.
> It's far abstracted from http, is an optional feature (skip if you can, or
> read if your filter must in order to transform) and trivial to implement.
> And it's typical of bytestream APIs.

I don't see how a skip feature would work in a push model API like our output 
filters - perhaps in a pull-model (like input).  But, there are so many other 
problems with the pull model that I think it's not worth the gain of a skip 
feature.  -- justin