rfc:remove_zend_api

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:remove_zend_api [2009/03/29 01:58] – Fill out solution and example pbiggarrfc:remove_zend_api [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== Remove reliance on Zend API ====== +====== Removal of the Zend API ====== 
-  * Version: 1.0+  * Version: 1.1
   * Date: 2009-03-27   * Date: 2009-03-27
   * Author: Paul Biggar <paul.biggar@gmail.com>   * Author: Paul Biggar <paul.biggar@gmail.com>
-  * Status: Early draft+  * **Status: Brainstorming: [[http://wiki.php.net/rfc/remove_zend_api/scratchpad]]**
  
 +===== Introduction =====
  
-A better way to provide a C API, with particular emphasis on decoupling extensions from the interpreter.+Currently, PHP's interpreter, the Zend Engine, provides access to its internals via the Zend API. This RFC provides a rationale for this access, by removing the Zend API.
  
-===== Introduction =====+This RFC does not describe how to remove access, and what to replace it with. That is described separately, in [[php_native_interface]]. The goals of this RFC are predicated on achieving the goals of [[php_native_interface]].
  
-** Naturally, this seems insane. Please bear with me. ** 
  
  
-===== What's the problem? =====+===== Why remove the Zend API? =====
  
 === Zend API === === Zend API ===
Line 19: Line 19:
 The Zend API is a large set of functions, macros and data-structures which are used to interact with the Zend Engine. It serves 3 major purposes, roughly in order of importance: The Zend API is a large set of functions, macros and data-structures which are used to interact with the Zend Engine. It serves 3 major purposes, roughly in order of importance:
  
-  * Used to write PHP's standard libraries, 3rd party extensions, and much of PECL +  * Used to write PHP's standard libraries, 3rd party extensions, and much of PECL. 
-  * Allows hot (performance-sensitive) code to be rewritten in C for speed+    * Allows wrapping of C/C++ libraries in order to allow the to be accessed from user-code. 
 +    * Allows hot (performance-sensitive) code to be rewritten in C for speed
   * Used to embed PHP into within C/C++ applications using the embed SAPI   * Used to embed PHP into within C/C++ applications using the embed SAPI
  
 === Problems === === Problems ===
  
-The main problem with it is that it constrains the implementation of the Zend Engine. The Zend API creates a tight coupling between the ZendEngine and its users, restricting greatly our ability to change the Zend Engine. By requiring backwards compatability with the Zend Engine, we are ensuring that the ZendEngine can only be modified in minor ways (although ABI changes are allowed for major versions). This holds the Zend Engine to design decisions made nearly 10 years ago, and prevent PHP from getting much faster in the long term. +The main problem with it is that it constrains the implementation of the Zend Engine. The Zend API creates a tight coupling between the Zend Engine and its clients, restricting greatly our ability to change the Zend Engine. By requiring backwards compatability with the Zend Engine, we are ensuring that the Zend Engine can only be modified in minor ways. This holds the Zend Engine to design decisions made nearly 10 years ago, and prevents PHP from getting much faster in the long term.
- +
-The Zend API also makes it difficult to write PHP extensions. Although most of the API is not terribly difficult to work with, concepts like copy-on-write, change-on-write sets and separation appear to be tricky concepts for many people. The only documentation is Sara Golemon's book, and the actual code is not well commented. I believe that a simpler way of writing extensions would be welcome. +
- +
-A number of other PHP implementations exist, such as IBM's Project Zero, Phalanger, Roadsend, Quercus and phc. Many of these projects find it very difficult to re-use PHP's standard libraries. Quercus and Roadsend have reimplemented popular standard libraries. Phalanger and Project Zero attempt to re-use the existing libraries by marshalling their data into the Zend API. This appears to be slow and error-prone. phc is designed around reusing the Zend API for compatibility with the PHP. This constrains many of the optimizations phc would wish to perform, since it uses the Zend API nearly everywhere. +
- +
- +
-===== What's the solution? ===== +
- +
-=== Design Criteria === +
- +
-  * Greatly reduce the coupling between the Zend Engine and its users +
-  * Support all major use cases of the Zend API +
-    * preferably simplifying each use case +
- +
- +
-=== Solution === +
- +
-Take the use case of wrapping a C library to expose its functionality in user space. The major idea is to "automatically" import C functions into a special namespace. The PHP library functions would then be comprised of PHP user space code which calls those C functions directly. That way it is possible to craft an API that is separate from the C implementation. +
- +
-Lets take a simple example - which is an idea for how it might work ijn practice. Assume we have a C library XXX, with 3 functions, x, y and z. We'd like to expose this in user space as a class called MyXXX, with methods a and b. We create a file with the signatures of x, y and z: +
- +
-xxx/sigs.h +
-int x (int, int); +
-void y (char*, int); +
-void z (char*, int); +
- +
-We then write our user space code: +
- +
-xxx/MyXXX.php +
-class MyXXX +
-{ +
-   function __construct ($username) +
-   { +
-       $this->username = $username; +
-   } +
- +
-   function a ($w1, $w2) +
-   { +
-      $foo = \internals\XXX\x ($w1, $w2); +
-      \internals\XXX\y ($this->username, $foo); +
-   } +
- +
-   function b ($m1, $m2) +
-   { +
-      $foo = \internals\XXX\x ($m1, $m2); +
-      \internals\XXX\z ($this->username, $foo); +
-      return $foo; +
-   } +
-} +
  
 +The Zend API also makes it difficult to write PHP extensions. Although most of the API is not terribly difficult to work with, concepts like copy-on-write, change-on-write sets, and separation appear to be tricky concepts for many people. The only documentation is Sara Golemon's book, and the actual code is not well commented. Although //zend_parse_parameters()// has simplified the parameter parsing somewhat, it seems that a simpler way of writing extensions would be welcome.
  
 +A number of other PHP implementations exist, such as IBM's Project Zero, Phalanger, Roadsend, Quercus and phc. Many of these projects find it very difficult to re-use PHP's standard libraries. They have chosen different strategies:
  
-===== Project Plan =====+  * Quercus and Roadsend have reimplemented popular extensions. This means that probably 90% of extensions are unavailable. It also means that future and private extensions cannot be available. 
 +  * Phalanger and Project Zero attempt to re-use the existing libraries by marshalling their data into the Zend API. This appears to be slow and error-prone. In particular, Project Zero reports speed problems from marshalling Unicode strings into the Zend API (and those are then passed to C libraries, possably requiring extra marshaling). 
 +  * phc is designed around reusing the Zend API for compatibility with the PHP. This constrains many of the optimizations phc would wish to perform.
  
-This is a simple design. In reality, it would need to be prototyped to determine how  
  
  
-==== Links ==== 
  
 +===== How to proceed ======
  
  
-===== Changelog =====+A proposed replacement for the Zend API is described in [[php_native_interface]]. However, to actually solve this issue, a decision must be made to not only use the PHP Native Interface to provide an interface between extensions and implementations, but also to disallow any external access to the Zend API.
  
 +This RFC is a means of achieving concensus on removing the Zend API in PHP 6, predicated on first achieving the goals in [[php_native_interface]].
  
  
rfc/remove_zend_api.1238291932.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools