httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src CHANGES
Date Wed, 01 Nov 2000 14:25:31 GMT
Ryan,
I completely disagree with this veto.  It is arbitrary and unilateral.
mod_ext_filter is a slick, direct and elegant way to bind the web server to
Unix style filters.  Yes, it is different but that doesn't make it bad. I
suggest a compromise: let it reside in modules/experimental for a release and
see what happens. If it doesn't get traction, then boot it out.

Bill

> rbb@covalent.net 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 modules.apache.org 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 | trawick@ibm.net | PGP public key at web site:
>      http://www.geocities.com/SiliconValley/Park/9289/
>           Born in Roswell... married an alien...


Mime
View raw message