At 11:15 PM 6/24/2002, Ian Holsman wrote: >Greg Stein wrote: >> >>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.
You miss the point altogether. The handler is the core FILESYSTEM handler itself. Why on earth should php worry about the distinction? Whether it resides in the filesystem, the sql database, the .tar archive or an SVN repository is all beside the point. To the extent that 2.0 provides faux-handlers that make setup simpler for old users to understand, fine. We have that. By 2.1 I sure as heck hope we rip out those kludges. The problem today is that the zend engine parses a file, not a stream. That's actually partly true, zend is set up for streaming, IIUC there are just a few bits missing to actually serve the content straight into PHP's zend engine from the brigade. There should be no significant slowdown if the brigade mechanics interact correctly. Creating both a filter and handler gives you two opportunities for bugs, security holes, exploits and the rest. Code that works in a single modality for multiple uses should be written in the single cleanest possible way. Bill
