rfc:php_native_interface

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
Next revisionBoth sides next revision
rfc:php_native_interface [2009/04/05 16:35] – Remove parts specific to remove_zend_api pbiggarrfc:php_native_interface [2009/04/09 11:15] – Remove duplicate text pbiggar
Line 6: Line 6:
  
  
-Design of the design of *phpni*, a native interface for PHP, designed to replace the Zend API.+Design of the design of //phpni//, a native interface for PHP, designed to replace the Zend API.
  
-See also remove_zend_api (TODO: link). +The need for such a native interface is described separately in [[remove_zend_api]].
- +
- +
-===== Why do we need a PHP Native Interface? ===== +
- +
-The rationale is explained separately in remove_zend_api.+
  
  
 ===== phpni: The PHP Native Interface ===== ===== phpni: The PHP Native Interface =====
  
-This describes the design of *phpni*, the PHP Native Interface. This design is in early stages. The stages required until completion are described later.+This describes the design of //phpni//, the PHP Native Interface. This design is in early stages. The stages required until completion are described later.
  
  
Line 69: Line 64:
 </file> </file>
  
-In order to interface between these two, it will be necessary to have a tool to automatically wrap the C functions. SWIG could be used to create this tool.+=== Interface === 
 +In order to interface between the PHP code and the C functions, a tool will be required to generate code. This tool will obviously be implementation specific. SWIG could be used to create this.
  
 === Zend engine === === Zend engine ===
Line 88: Line 84:
 Since PHP extensions are no longer written in the Zend API, other PHP implementations, such as Roadsend, Project Zero, Phalanger and Quercus should be reuse the libraries without difficulty. In addition, if the coupling is between the interpreter and its components is simple enough, it may be possible for other implementations to be slotted in directly. However, though this would be a nice side-effect, it should probably not be considered a priority. Since PHP extensions are no longer written in the Zend API, other PHP implementations, such as Roadsend, Project Zero, Phalanger and Quercus should be reuse the libraries without difficulty. In addition, if the coupling is between the interpreter and its components is simple enough, it may be possible for other implementations to be slotted in directly. However, though this would be a nice side-effect, it should probably not be considered a priority.
  
 +===== Problems with current design =====
 +
 +As the design progresses, problems will be identified, which must be solved. This section will keep track of them:
 +
 +=== Problems to be dealt with ===
 +
 +  * Strings:
 +    * How can we identify that an int field is the length of char* field?
 +    * Who will be responsible for freeing passed memory?
 +    * How do we decide whether to make a copy of the string?
 +    * How do we know if we can modify the string in place?
 +      * TODO: look at how JNI does it
 +
 +=== Problems solved ===
 +
 +  * Performance of say, pointer arithmetic, will suffer
 +    * With the basic design (v1.0), it should be simple to put a C layer above the C library, and wrap that instead.
  
 ===== Similar projects ===== ===== Similar projects =====
Line 93: Line 106:
 === Non-PHP === === Non-PHP ===
  
-phpni differs from many of these in that it is designed not to add new features, but instead to replace an existing facility - the ability to call C libraries. As such, dynamic linking is not part of the spec.+//phpni// differs from many of these in that it is designed not to add new features, but instead to replace an existing facility - the ability to call C libraries. As such, dynamic linking is not part of the spec.
  
   * ctypes (Python) http://docs.python.org/library/ctypes.html   * ctypes (Python) http://docs.python.org/library/ctypes.html
Line 104: Line 117:
   * Haskell 98 Foreign Function Interface http://www.cse.unsw.edu.au/~chak/haskell/ffi/   * Haskell 98 Foreign Function Interface http://www.cse.unsw.edu.au/~chak/haskell/ffi/
   * CFFI (Common Lisp): Common-Lisp FFI: http://common-lisp.net/project/cffi/   * CFFI (Common Lisp): Common-Lisp FFI: http://common-lisp.net/project/cffi/
 +  * SICStus Prolog FLI: http://www.sics.se/sicstus/docs/latest/html/sicstus.html/Mixing-C-and-Prolog.html --- //nlopes 2009/04/06 18:17//
  
 === For PHP === === For PHP ===
Line 121: Line 135:
     * perhaps readline?     * perhaps readline?
     * Manually write interface code between the header and the PHP code.     * Manually write interface code between the header and the PHP code.
 +    * Solve problems raised in email discussion
 +      * Look at other implementations, in particular JNI
  
   * Discuss requirements with other PHP implementations   * Discuss requirements with other PHP implementations
Line 130: Line 146:
  
   * Convert entire set of PHP extensions   * Convert entire set of PHP extensions
- 
- 
-Naturally, before the last step it will be necessary to get consensus from other internals developers that this is a good idea. It would be worthwhile to produce a document discussing the experience so far. 
  
  
  
rfc/php_native_interface.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools