Re: Interested in Abstract Extension API and Dependency Interface

Hi, My Application http://www.xvpj.net/gsoc-09-application-php-abstract-extension-api-and-dependency-interface/ Please comment on this and give suggestions for improvements. Thank you Varuna On Tue, Mar 31, 2009 at 8:31 AM, Varuna Jayasiri <vpjayasiri@gmail.com>wrote: > Hi, > > On Tue, Mar 31, 2009 at 7:49 AM, shire <shire@php.net> wrote: > >> >> >> 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. > > > Now I'm pretty clear on how this could be done :). I would go ahead with > the idea of including the prototypes in the caller's headers. I'll complete > the application with this design, and publish it for comments. I'll change > it if a better approach comes up in the next few days. > > >> >> >> 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. >> > > Yes, I now get the performance issue with this design and that it's not > very suitable solution :P. > > >> >> 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. > > > I forwarded the two previous mails to the pecl-dev list. I think there > weren't any replies because it was during the weekend. I'll cc to the > pecl-dev list and not to the gsoc list here onwards. > >> >> -shire > > > Thank you > Varuna >