httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject PHP as a filter (was: Apache 2.0 Numbers)
Date Tue, 25 Jun 2002 03:19:56 GMT
On Sun, Jun 23, 2002 at 08:52:09PM -0700, Ian Holsman wrote:
>...
> The main difference that I can see is that php is using a filter.
> i'd say that php's performance would increase to 1.3 numbers when
> they write there sapi interface as handler NOT a filter.
> until then php's performance will always be worse in 2.0, as they
> are using the wrong set of hooks (filters) to communicate with 2.0.

No frickin' way. PHP is a filter, not a handler. Something else generates
the content, then PHP parses it and executes it.

If you make PHP a handler, then you will *only* be able to run PHP on
content that *it* comes up with. You'll never be able to run PHP on custom
data sources.

Concrete example? Sure. Subversion stores its content in a custom, versioned
repository. When a request is made, SVN generates the content from its data
store. Since PHP is a filter this means that we can serve up .php files
right out of a Subversion repository! How frickin' cool is that?!

[ I also know some guys are working on a MySQL backend; it would kick ass to
  store .php files in the MySQL database, and PHP-process them as they get
  yanked out of there. ]

It would be a sad, sad, day if PHP ever reverted back to a handler rather
than operated as a filter.

If it was a handler, it would have to know about every single data store out
there that somebody might want to use for producing Apache content. I doubt
they want to take that on :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message