Re: Interested in Abstract Extension API and Dependency Interface

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