Fwd: Interested in Abstract Extension API and Dependency Interface

---------- Forwarded message ---------- From: shire <shire@php.net> Date: Tue, Mar 31, 2009 at 7:49 AM Subject: Re: Interested in Abstract Extension API and Dependency Interface To: Varuna Jayasiri <vpjayasiri@gmail.com> Cc: gsoc@lists.php.net, andrei@php.net Hi Varuna, Varuna Jayasiri wrote: > I think I might have misread something in the initial design section :P. > It says that a extension specific structure would be used, which I now > understand as different extensions registering different api structures; > i.e. there is no generic structure as extension_api_t but there are > different structures for each extension. This solves the above problem. > Yes exactly. However, if an extension specific structure is used, wouldn't exposing > it to other extensions be done at the compile time (via > PHP_INSTALL_HEADERS)? Won't this require testing out whether the > required extension is available using macros > Yes, this is a potential downside. I envisioned this being done in either the way you described with a simple header file check for an installed extension. Of course the pitfall with this approach is that you can't build an extension with a particular API support unless it's actually installed on the system. The other option I really had in mind would be for the calling extension to go ahead and include the prototypes it needs itself in it's own header files. While this of course defeats some goals of including a header file, but it's of a limited scope and multiple prototypes could be included for different extension versions so long as it's validated before use with. So, isn't it convenient to use dynamic registration as I previously > described, with an improvement to overcome the efficiency issue. > e.g. (rough) > > /to register/ > > PHP_API_FE(func) {#func, zif_##func} > php_api_functions func_set[] = { > PHP_API_FE(fetch), > PHP_API_FE(store) > }; > > php_register_api(&api, func_set) > > /to retrieve/ > > PHP_API_FUNCTION fetch = php_get_api_function("myextension", version, > "fetch"); > fetch(key); > > /or/ > > PHP_API_FUNCTION_SET apc_api = php_get_api_function("myextension", > version); > PHP_API_FUNCTION fetch = php_get_api_function(apc_api, "fetch"); > fetch(key); > If I understand correctly, it sounds like what you're proposing (please correct me if I'm wrong about the code above), is that we could avoid including function prototypes and instead treat all API functions as regular internal PHP functions that are exposed to user space (or some similar structure that avoid explicit declaration of function arguments and return values, in favor of generic ones)? I think this is possible, however, I would expect two problems with this approach: - Repeated calls to internal functions will likely be slower due to the argument handling, validation, etc. We'll also loose performance simply because you loose the efficiency of passing the parameters as normal C functions. - If these aren't much different than PHP_FE entries, then we could simply call via user space functions and get the same functionality with functions like version(), function_exists(), and internally zend_call_function etc. An argument could be made here of course that an extension wanting this functionality could simply do the above, but I don't think this offers the performance requirements that I see some use cases needing. For example calls that are done repeatedly in a real application such as serialization, storing data in a caching extension, reading data from a remote server etc. I would also, as Pierre suggested, invite you to solicit input from the PECL list in general as this is an idea that hasn't been exposed at all to many of the other PECL developers and it might be useful to get further input. -shire