Important stuff to finish: PPP members/PPP methods, support of overloaded extensions, possibly differentiate between class and namespace as discussed with Stig in Germany. *Responsibility*: ~Zeev~, ~Andi~, ~Stas~ *Timeframe*: Couple of months for first part and extensions will be ongoing while PHP is being fixed. Things to leave for later versions: Native aggregation support, accessing static members via object and not class. *Responsibility*: ~Andi~, ~Stig~? *Timeframe*: ? *Responsibility*: ? *Timeframe*: 1 month Identify the extensions that are not thread safe by design or due to dependant libraries and identify them as such. If possible try to resolve thread safety issue via code improvements (if php code or patches will be accepted by library maintainers). For situations where thread safety cannot easily be acheived a flag in the extension API is set so PHP can identify non-thread safe extensions. These extensions will not be loaded in a ZTS compiled binary (unless it is cli/cgi). *Responsibility*: Spiderman or someone similar with superhuman powers *Timeframe*: ? Environment variables defined in the CGI spec need to be verified in each SAPI module that they conform to the CGI spec correctly. If they do not, the SAPI module needs to fix the variable prior to script execution. Having this conformity will aid in having PHP scripts run correctly under different sapi modules. *Responsibility*: ~Shane Caraveo~ & each sapi module owner *Timeframe*: ? (but shouldn't be much effort, most modules are probably ok) Implement a SAPI input filter hook that will get called just before registering a variable in the treat_data/post_handler hooks. Make sure this is also done in mbstring Provide access functions, or perhaps a new $_RAW_GET/POST/Cookie set of superglobals to get at the unfiltered data Provide a .ini directive which allows people to set their input filter to one of the built-in strip_tags, htmlspecialchars or whatever other internal function might be useful here. (The main benefit of this is to make it easier for people to solve the XSS problem once and for all without having to go through every line of their code and adding input validation/filtering everywhere) *Responsibility*: ~Rasmus~ *Timeframe*: Yesterday Porting java, com, dotnet, xmlrpc, corba, soap and python, srm (are there more ?) to work with the new oo api and preferably by using ext/rpc. *Responsibility*: ~Harald~ *Time frame*: 2 months (but i have to wait for a few engine features first) Each OO extension has to be revised and rewritten to fit into the new OO model. We should decide which extensions are a must to have for the release and which can be ported by the maintainer later as a separate pecl release. A list of extensions to be extended that have to be investigated: * browscap * aggregate * all *sql extensions (*_fetch_object) * domxml (seems like christian is rewriting it anyways) * ming *Responsibility*: ~Harald~ (, extension maintainers) Complete rewrite, leveraging the new MySQL 4 / MySQL 5 features. *Responsibility*: ~Georg Richter~, ~Zak Greant~ Timeframe: ? Rewrite DOMXML and incorporate all (or most of) W3C-DOM2. Use the new ZE2 features (Exceptions, setter/getter). Add SAX(2), XML Schema. XSLT, HTML, XPath, XPointer, DTD Validation will still be supported, have to find a meaningful API for it. Break BC, warn users now. Look at the libxml2 patch by lukas schröder and see if we can prevent memory leaks with it (anyway, getting rid of mem-leaks and intelligent memory management is on top prio...) In the longer term, domxml (or another name, as with todays features domxml is a little bit misleading) shall be the main xml-class, which covers most of what's needed for decent XML support in PHP ;) But there is certainly place for others like Sablotron etc. *Responsibility*: ~Christian Stocker~ *Timeframe*: ? Extending the test suite with atleast a test for every function in an extension that doesn't require external resources. Also developing an automated test thing which cvs ups's, compiles and tests the build on a daily base on as much platforms/extensions as possible. The test suite will also be extended to support threaded testing and testing for differing sapi modules (via http calls or other methods). *Reponsibility*: ~Derick~ (, extension maintainers) *Timeframe*: 3 months