Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43633
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain uk.ibm.com designates 194.196.100.161 as permitted sender)
In-Reply-To: <af54caaf0903301606s26d87824oedd1167db8f0cc10@mail.gmail.com>
References: <af54caaf0903301606s26d87824oedd1167db8f0cc10@mail.gmail.com>
MIME-Version: 1.0
To: Paul Biggar <paul.biggar@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Message-ID: <OFAF80FC3F.218AFCED-ON80257590.00297673-80257590.00355E73@uk.ibm.com>
Date: Mon, 6 Apr 2009 10:42:49 +0100
Content-Type: multipart/alternative; boundary="=_alternative 0034BC5180257590_="
Subject: Re: [PHP-DEV] RFC: Removing the Zend API
From: rob_nicholson@uk.ibm.com (Rob Nicholson)

--=_alternative 0034BC5180257590_=
Content-Type: text/plain; charset="US-ASCII"

Paul Biggar <paul.biggar@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






--=_alternative 0034BC5180257590_=--