httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: Thoughts on filter-chain composition
Date Tue, 12 Sep 2000 10:02:41 GMT
TOKILEY@aol.com wrote:
>
>The way you are actually designing your filtering there can NEVER be
>a one-to-one mapping with other useful code like NetPBM. There will
>always have to be Apache-style filter wrappers written for anyone to
>use such code.

I think that is impossible to avoid.

>The NetPBM thing is just an EXAMPLE. It works for me because
>I made it work. It was what I needed. It won't ever work with the
>current Apache filtering design approach without major changes
>being made to entire NetPBM source code. Pity.

And I think that is bollocks. The design I sketched in the previous
mail would not require fiddling with the internals of NetPBM unless
its API is irredeemably brain-dead (which I doubt).

>Looks good on paper... but you are again just pushing a little
>more of the big toe into the water and hoping you won't have
>to dive in.

Yup, that's the point of my previous message.

>Even with Content-Encoding style filtering there are times when the
>pre-content handling information isn't all you need to know. You may
>still need/want to install other filters into the chain to help get
>the job done AFTER the processing has started.
>
>Example: The next version of ZLIB will allow multiple packed
>compression images all in the same compression object 
>( sort of like a 'collage' of compression objects ) and is styled
>after multi-part MIME files or Multi-frame GIF images. If 
>a filter needs to 'unpack' this stuff on the fly it might need
>different 'filters' to do it and it won't know what it needs
>until it reaches the right point in the stream to know.

You're mixing up two functions here, one which is within the limited
scope that I suggest (i.e. on-the-fly Content-Encoding: gzip
compression) and one that is not (on-the-fly extraction of a resource
from a complex zlib archive). One is HTTP-level, one is content-level.
In-scope, out-of-scope.

Tony.
-- 
en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y    dot@dotat.at
eatp o v eiti i d.    fanf@covalent.net

Mime
View raw message