Re: Function caching...

Kristian, I have no problem at all with you, or others, attempting to implement this daemon within the php4 source tree. To be honest, even if I did (which I don't), I'm not in a position to stop you anyway. We have differences as to our estimates of how much of a change this would require, and whether you can do it without severe modifications to the core PHP source code. My understanding is that in order to implement the kind of functionality you're talking about, it would require much more far-reaching changes to PHP, than simply add a thick SAPI module. What I was saying all the time, is that I would generally oppose such changes, if they prevent PHP from working in the 'standard' way in which it works today. If you can do it - you're more than welcome! Zeev At 19:20 11/12/2000, Kristian Köhntopp wrote:

Zeev Suraski wrote: I didn't say that it will require big changes. Much like the fact that I can plug the Zend Engine in MySQL doesn't mean that users should start serving their Web pages off stored procedures, the fact you can create a Zend engine based application server doesn't mean that PHP should *become* that application server. It doesn't matter if you'll have to change 2 lines, 500 lines or 10K lines... What matters is what you end up with. I do not know what I will actually end up with. What I do _want_ to end up is quite simple, though. I want to end up with is a long running process running under a user id different from the web server, listing on an ONC RPC port or a similar communication channel for requests, having a pool of threads and a pool of database connections governed by a ressource management mechanism similar to what Apache offers for number of worker threads (StartServers, MinSpareServers, MaxSpareServers, MaxClients like limits for threads and DB connections). I want that thing to keep compiled bytecode in memory, r/o and shared between the threads, if possible and I want to limit that amount of memory in a LRU style fashion, so that unused bytecode is being dropped in low memory situation, but compiles are saved when there is enough memory. I want that thing to be able to execute unmodified PHP scripts, if possible, dropping ressources at script end as before, but keeping bytecode around. I want that thing to keep session variables actively, no serialization needed, and to work with pooled ressources such as database connections in a sane manner. That way, references and ressources will not be a problem as session variables. And I believe that this will be slightly larger than your average sapi interface, but not so much that it would not fit into a sapi/ directory in your normal PHP distribution, including the stub program as a CGI and a module version. I would not call this breaking the language, in fact the average user not using session_*() functions probably will not even notice the difference besides faster execution times. Now please tell me where the hole is in my reasoning. Kristian -- Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 Using PHP3? See our web development library at http://phplib.netuse.de/

-- Zeev Suraski <zeev@zend.com> CTO, Zend Technologies Ltd. http://www.zend.com/