Paul Biggar <paul.big...@gmail.com> wrote on 31/03/2009 00:06:33: > > I've added a new RFC to the wiki > (http://wiki.php.net/rfc/remove_zend_api). It details a plan to try > and decouple the Zend engine from the libraries, in order to allow > large scale changes to the Zend engine in the future. The RFC > describes a prototype phase of the project, which could reasonably be > done within a GSOC project, so I have added it to the GSOC 09 page > (http://wiki.php.net/gsoc/2009#prototyping_removal_of_the_zend_api).
Hi Paul, This is certainly an interesting project. I work on ProjectZero and I see from the wiki that you have looked at the approach we have taken. As you correctly point out Project Zero wants to allow users to re-use the majority of PHP extensions without re-writing them and as you observe, using the existing interface as we do today brings a number of problems. We would also like to enable others to attach arbitrary PHP extensions written in C to ProjectZero. So we would like to see the "PHP Native Interface" be successful and would like to help if we can. A few of the most significant issues from my perspective: 1. PHP arrays present a significant issue. Look at the code in array.c. Much of this code rummages directly in the internals of the Zend Engine implementation of hashtables and needs to in order to achieve reasonable performance. We were unable to attach this code to a JVM implementation of PHP and rewrote it in Java. Perhaps we will need to accept that the array manipulation functions and a small set of other built-in extensions must continue to use the internal interfaces. Its also worth mentioning that today many extension make use of the Zend HashTable implementation for their own purposes (as a general library function) in addition to using the HashTable as an interface. 2. Memory management. If we separate extensions from the internal implementation of Zvals then it becomes difficult to manage memory allocated by the extension during a request. This "falls out in the wash" today because extensions participate in the Zend engine's reference counting scheme which allows memory to be de-allocated once the refcount falls to zero. 3. A logistical problem seems to me that in order for this project to gain traction a significant number of extensions would need to adopt it. In order for extensions to adopt it, we would need to convince their maintainers that the project had traction. I wonder whether improving the interface could be combined with some of the unicode work so that the resulting porting work for unicode was simpler? Rob Nicholson Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
