Re: [PHP-DEV] Function caching... From: Zeev Suraski (zeev <email protected>)
Date: 12/11/00

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 <email protected>>
CTO, Zend Technologies Ltd. http://www.zend.com/

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>