Greg Stein wrote: > 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. >
It should also be a handler because in the normal case it just reads a flat file off the disk. so that in the >general< case you won't get the slowdown penalty for the people who are going to be use it ontop of something else. I'm not saying that you shouldn't have a filter mode.. just that you should have a handler mode as well. (and so should mod-include IMHO) --Ian > 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 >
