httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: Thoughts on filter-chain composition
Date Thu, 14 Sep 2000 15:32:57 GMT

In a message dated 00-09-14 14:55:21 EDT, Tony Finch writes...

> TOKILEY@aol.com wrote:
>  >
>  >I hear you. 'Black Box' approach is easier to code.
>  >What you are saying is that each and every installable
>  >filter has to assume that it is handling a request as if
>  >it were a regular HTTP internal redirect ( whether it is
>  >or not ). You get metadata, you get data... do your thing.
>  
>  Except for the fact that that isn't the way HTTP internal redirects
>  works. They take an HTTP request and produce an HTTP response, wheras
>  a filter takes a data stream and produces a different data stream.
>  (The data stream has some attributes like content type, content
>  encoding, transfer encoding, but it isn't a full HTTP response -- see
>  the distinction between entity headers (which filters may change) and
>  response headers (which they may not) in RFC 2616.)

Yes, yes. I know. You are taking what I said too literally.
I only meant that what Ken is describing creates the same
sort of "point of view" from a processing standpoint. 

>  >You mean you cannot imagine a scenario where a primary
>  >filter needs to install some cool sub-filters to help it get
>  >the job done and that little 'family' of filters are never supposed
>  >to know that they are related and working on the same original
>  >data stream? I sure can.
>  
>  I don't see why they have to be apache-level filters rather than being
>  encapsulated inside your own code, especially if your sub-filters are
>  implemented by an external library like NetPBM.

You are simply emphasizing my original point. 
You (others) just don't get it (yet) but that's OK.
It will all come out in the wash.

If truly cool and useful data sub-filters that I write to help ME process
data streams are permanently imprisoned inside my own code space then 
no one else can use them if/when they might need to. We are right
back to the same limitations imposed by CGI. The duplication of code
and functionality just turns into a nightmare as it has with CGI.

Making other sub-filters standard Apache filters that can be 'inserted' 
at the right place by anyone is more like the equivalent of having 
some really cool and useful ( and tested! ) public API calls, only they 
are Apache filters.

You seem to be forgetting one of the prime directives of 
good programming...
Never force anyone to duplicate tested/working code if 
you don't have to.

There's a palpable lack of imagination going on here.
The 'Black Box' approach with static config will get you out
the door so just go for it.

Just remember to keep (all) the filtering control recs 'public'
and don't try to make them inaccessible 'private' methods 
or class items like OOP would and you will be OK for later.
So far all seems to be well... just don't make any bad moves.

Yours...
Kevin Kiley
CTO, Remote Communications, Inc.
http://www.RemoteCommunications.com
http://www.rctp.com - Online Internet Content Compression Server



Mime
View raw message