httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: cvs commit: apache-2.0/src CHANGES
Date Wed, 01 Nov 2000 13:28:19 GMT writes:

> > a look at it first.  Of course *I* think it is valuable addition and
> > that by making filtering trivial to implement it will open up more
> > minds to what can be done, which will hopefully result in more filters
> > being written (hopefully which don't all run out-of-process) :)
> But that's just it.  This doesn't make filtering any easier, it makes
> external filtering easier.  If you are going to do something like this, it
> makes MUCH more sense to write a simple CGI script to do it and then feed
> that to Apache filters.

Making external filtering easy makes filtering easy...

To do the task of the c->html filter example in the documentation,
it is cheaper in terms of implementation time, execution time, and
system resources to use mod_ext_filter to do it when compared with
the *typical* CGI implementation.

It is business as usual to use Unix-style filters to perform
transformations on data that is to be delivered to a client.  The
simple way to do it pre-2.0 is to write a CGI program to feed the
output through the external program.  mod_ext_filter simplifies it and
makes it faster.  It also opens up more function because the old
filtering/preprocessing implementations wouldn't work with other
filtering/preprocessing without code changes to the CGI.

> Or, use mod_perl or mod_python or mod_php to do something like this.  I
> don't see what this adds one way or the other to the web server as a web
> server.  This module belongs on or linked to off your
> own site, not in the core dist.

This is the real issue with your veto, and even though there are a
number of responses to your argument regarding limiting "Apache httpd"
to core HTTP support, the veto remains and I will pull mod_ext_filter
out of the experimental directory tonight (or so).  I think that this
is a shame, as mod_ext_filter promotes a big benefit of 2.0.  It makes
a (admittedly modest) step towards bringing filtering to more people,
which should in turn result in more in-process filters after folks
play with it a bit (not that there is necessarily anything wrong with
out-of-process filters; plenty of those are deployed today, albeit
with an extra CGI child process to get it to work and the inability to
plug and play with other types of filtering).  IMHO, less people
will play with filtering as a result. 

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message