httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Thoughts on filter-chain composition
Date Tue, 12 Sep 2000 01:01:36 GMT

In a message dated 00-09-11 20:31:11 EDT, Tony Finch writes...

> wrote:
>  >Tony Finch writes...
>  >
>  >Best example I can think of is a filter that actually works
>  >right now and is VERY necessary for any next generation
>  >HTTP Server...
>  >
>  >The dynamic filtering of graphics content for different User Agents.
>  I think your suggested way of going about this is completely wrong.

Roger that. It's a free country. 

All I can do is walk through your response and try to re-iterate some
things so please allow me to do that.

> Before you get to the content handler stage you know the User-Agent
> and the resource requested. 

Yes. No question... but this information in no way tells me what
is going to need to happen from start to finish... only what BASE 
filter needs to be called first to start the filtering process.

There is nothing anywhere in an HTTP request rec->xxxx ( at this 
pre-content handler stage ) that will provide all the answers. The 
only real answers lie inside the object itself.

> Therefore you know the input image type
> and the output image type, 

If you mean MIME type...Yes. In the example given the IMT 
doesn't change... only the actual content of the requested object.
Sometimes the IMT will change ( for devices that only support 1
type of graphic ) but that's a needless differentiator in relation
to this thread.

> so you can set up the appropriate filter stack. 

Before the filtering begins? 

Bzzzt. Wrong. Sometime, yes, sometimes no. 

All I can do is know where to START... not where it all
needs to go to achieve the final result. Not yet.

The successfull filtering of the content does not simply depend
on MIME type in and MIME type out. It all depends on what is
actually INSIDE the object itself.

> This happens *before* the handler stage, and the filters do not
> have to make any decisions.

Wow. Did you even read the prior email where it shows the 
decisions that have to be made? There are any number of
decisions that must be made DURING the filtering process that
can ONLY be made AFTER the filtering has already started.
>  A filter should do one thing and do it well: 

Absolutely. 100% agree. That's the problem.

NetPBM graphics/image libraries are composed of many
different little 'worker' filters that do exactly that... one thing
and one thing only. The PROBLEM is that in order to let 
all these fine little 'filters' do their thing and produce the
desired final result you HAVE to be able to 'set them up' and
include them in the filtering process on a dynamic basis.

> it should not change its behaviour according to the 
> circumstances of the request; 

Wow. I guess that's a limitation on any filtering scheme that
I am not willing to accept. I really don't see how you think the
entire scheme is going to be able to accomplish anything
sophisticated at all WITHOUT being able to adjust what happens
based on the 'circumstances of the request'. 

This doesn't just apply to the 'graphics conversion' example I
was trying to make. I can think of a hundred HTML conversion
examples where any particular filter will want other 'single
purpose only' filters to kick-in and help based on the 'circumstances
of the request'.

Maybe a better term might be 'the circusmtances of the content'.
This is what can, and will, most often require the use of other
neat and tidy little 'single purpose filters' to 'kick-in' in the
'right place'. That 'right place' can only be determined by
the base filter itself or others that are participating in the

> instead the filter stack should be set up right in the first place.

Right for what? Again... did you not read the previous message?

'In the first place' is relative. Sometimes the 'first place' you find
out what you need to do is only after the actual filtering has started.

You really must be assuming that simply knowing what a file
extension is or what a MIME type says is all that you should
ever need to know to filter anything. This is simply not reality.

Kevin Kiley
CTO, Remote Communications, Inc. - Internet Content Compression Server.

View raw message