Re: Re: cvs: php4 / TODO

Chuck Hagenbuch wrote: > > Quoting Sebastian Bergmann <sb@phpopentracker.de>: > > Bernd Römer is currently building an Application Server framework in > > native PHP but native support would be better somewhat, I believe. > > Could someone define what an application server is? I hear it all the time these > days, but I'm not sure what it's supposed to provide for me... Well, the basic idea is to leave the request based architecture and get over to an event based one. That means you have some kind of permanently running "server" process that starts "child" processes and offers them access to certain resources. Such a permanent running process can't be realized with any CGI programm on the apache. The apache has a request oriented architecture. It starts child processes whenever it needs one to handle a request and kills them afterwards (some keep alive but basically they get killed at some point). To do web -application- development you have to keep some state information between certain requests. This is why we have sessions. Our sessions are quite nice but imagine we could serialize resource links as well. Think of the fine day that we don't have to reopen a mysql connection which is a time consumpting task on every request. How could we get to that point that we can keep resource links withing requests? We need a permanent running server process that holds and shares certain resources (resource links, data,...) with its (request based) child processes. As you can see this would give us a performance boost as we can widely avoid session data serializing on slow mediums (filesystem, database, ...). Turning PHP in such a architecture is a hard job. You basically need three things: events, a mechanismn that can detect memory leaks and finally thread safety as one step to provide load balancing features. PHP has a relatively small thread-safe kernel (Zend) which is surrounded by a server abstraction layer and lots of PHP modules (libXML, MySQL, ...). PHP has gathered several external libraries over the years just like a borg. We don't know anything on the reliability (ok, sometimes...) of these libraries - are they always thread safe, do they have memory leaks, etc. If we had a permanent running php server process it must be very robust. Are all of your modules robust or might some of them tend to leak? We can't say that all of them fill our needs (thread-safe, no leaks). That's why fumanchi's (Bernd Römers) attempt with a permanently running PHP simulating a webserver using some socket functions is damned to be incomplete and will likely fail. Sorry, fu - that's my honest opinion. It's like the parser of my api documentaion generator: broken by design (yes, it will soon be improved...). Modifying PHP is not easy, I guess it would take two years to do so, not because the Zend kernel is not prepared to offer us the neccessary features but because of the external libraries included in php. Ulf