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/
