Bruno wrote: > Bryan a écrit : > > I think you guys got some incorrect info about PHP. A variety of > > execution options are available, such as FastCGI and in-server > > modules. > > mod_php, yes, but that doesn't change anything to the fact that it has > to rebuild the whole world on each and every request. Not the same as a > true long-running process.
> So, yes, you COULD write a cli PHP app, daemonize it, and add a mod_php > / FastCGI / whatever request handler to interface the cli app with the > web server, but that would be kinda pointless, wouldn't it ? I think I see what you mean -- correct me if I'm wrong: You want to keep complex application data structures around between requests. That sounds appealing in terms of efficiency, but it's bad for scalability and robustness. > > PHP frameworks generally allow and encourage application code > > to be independent of the underlying plumbing. > > This is debatable at best. PHP code (except cli PHP code of course) is > written without any care for persistent global state, concurrency > issues, race conditions etc - because it's written with the idea that > the code serving a request will be runned in total isolation. CGI > heritage here, obviously. No, that's good web-app structure, regardless of language and server interface. If we keep persistent global state in a shared database rather than program variables, then we can run the app in multiple processes and, if our service hits the big time, multiple hosts. > And please note I'm not criticizing this > design- just pointing one of it's consequences. > > > Many large, > > sophisticated, high-volume web apps are in PHP. > > Did anyone pretend otherwise ? How about this howler: "The PHP execution model (mostly based on CGI FWIW) tends to be a bit unpractical for non-trivial applications". -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
