httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src CHANGES
Date Wed, 01 Nov 2000 11:36:03 GMT

In a message dated 00-11-01 08:31:47 EST, Jeff Trawick writes.

> 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.


I think the basis for any reluctance to simply ship such a 
useful and cool piece of code with Apache is some subtle
concern that if people start using the 'easy' way out to
do things ( Just shelling out to binaries instead of writing
integrated server code ) that the performance of Apache 
will degrade when independent testing is performed.

Of course it will. There is no way that shelling out to handle
requests can ever be 'faster' than linking code into the
same process space as the Server. It's just a given.

But so what? Just make sure that if anyone does some
serious benchmarking that it's against the core code
rocking and rolling and NOT against something that
is nothing more than a gigantic HTTP batch file receiving
requests ( Shelling out ).

People already know to break their benchmarking stats
out into 'fair' categories shuch as 'Server handling internal
requests' and 'Server handling CGI requests' so there's
no reason to assume the mod_ext_filter won't be correctly
included in the CGI performance category so as not to
show Server degradation in benchmarks.

It's a REALLY useful little tool AND a good way for
someone to see an 'example' of filtering without getting
a headache. What's the big deal? Toss it into /modules/examples
and/or /modules/experimental and be done with it.

Just my opinion, of course.

Kevin Kiley
CTO, Remote Communications, Inc.

View raw message