Does "not up to date" mean the code isn't working with current releases of php 4 or 5? I'd be interested in giving it a try.
I believe this is the case. AFAIK the APC library doesn't support PHP5 or at least it didn't when I looked at it. If you want to pitch in support for APC you should just download it (or PEAR INSTALL it from the command line to try it :) )
Forgive my ignorance of Apache and PHP internals, but I'm not
understanding the concept of your implementation. I'm not enivisioning
allowing a PHP script to be able to meddle with the Apache request
process.
I'm picturing an extension that would simply not allow an uncautious or
unknowing scripter to ruin the server, but would only allow him to store
all his app defs and data model startup stuff in a one-shot performance
booster. It could even do it in a separate (CLI?) interpreter and copy
the data over (but only once!) to the Apache-embedded interpreter using a shared memory resource... hmmm.
So your process is something like (correct me if I misunderstand):
<php_script>
- have a PHP script with all global variables and class definitions that will be available to *all* scripts
- parse the PHP file to generate default values for variables
- as a side note: would this include any autoglobals such as $_SERVER, $_ENV, etc. ? I would think not at least for our first version.
- have a function translate all object definitions into the binary version of the definition and return that definition as a string.
- have a function translate each PHP variable into the binary value and return these as a string as well.
- write all of these strings to some file (test.static)
</php_script>
Restart server. Here is where I get really fuzzy, mostly because I have never written an extension. ;)
<extension>
- During MINIT
- Lock file (test.static) for reading
- We read from the source file (test.static)
- We initialize the non-object variables in a PHP-usable form
- We *try* to initialize objects. Likely to be some issues here, for example, when a class definition changes.
- As a side note, should we create a superglobal array to store these global variables similar to $_SESSION? Maybe $_SHARED? It is likely a pain to implement, but would be cool. :)
- Module needs a fetch function to get the value in shared memory.
- It needs to get a "lock" to read to that part of shared memory (forgive me but I don't know the right term here)
- For objects, this needs to check access level (private, protected, public) and return appropriate errors
- Module needs a write function to write to shared memory.
- It needs to get a "lock" to write to that part of shared memory
- For objects, this needs to return appropriate errors for modifying properties (i.e. private, protected, public) and return appropriate errors
- During shutdown (I think it's called MSHUTDOWN)
- Lock file (test.static) for writing
- Recreate the test.static file
</extension>
The above suggestion is quite messy and probably not thread-safe, but it's a start. ;)
-- Teach a person to fish...
Ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html PHP Manual: http://php.net/manual/ php-general archives: http://marc.theaimsgroup.com/?l=php-general&w=2
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
