Re: Re: Interested in Abstract Extension API and Dependency Interface

Hey, Overall I think your application looked really good. I personally love the idea for this as the current way to share such functions is really awkward. I do have a few comments on the overall design though. i am a bit uncomfortable about the use of a struct to pass around the functions. This leaves extensions needing to either awkwardly include a header form that extension at compile time (thus requiring the extension to be available on the machine its being compiled on) or to keep a copy of the struct definition within the extension wishing to use it. Neither solution seems all that great. The first is just awkward and will make building a pain. If I were to build an extension I would need to have those other extensions available and compiled on the same machine by the same compiler (people usually don't switch compilers between extension builds, but it is possible that some compiler out there might mess with the struct alignment and not represent it the same way). Of course the second solution has the same problems as the first (minus actually needed to have the extension). However, the second option of just keeping a local copy of the struct definition means the API maintainers really cant ever get rid of or reorganize the struct. This doesnt seem to be much of an improvement over the current hackish way this is being done now. I personally feel that fetching just one function at a time seems like the better solution. The problem with this of course is that it would require more function calls and more hash table lookups. But, I think this in practice should be trivial. If extension dependancies could be resolved then all that would need to be done is for the extension wishing to make use of the API to retrive the pointer to the function on MINIT and save it somewhere (probably its globals struct). Alternativly, If it is a one, or few use call then the lookup could just be done directly before the call. However, this then gets in to the issue with function prototypes. However, I feel that these will change much less frequently than the struct might. Also, I suppose API version could be used to select the correct function prototype if it changed at runtime and cast/call it apropriatly. Should this be part of PHP or Zend? It seems to me that most extension handling is done by Zend. Also, the names of some of the function names sound a bit off to me (granted this is really just personal preference). Something like php_exists_api migth be better as php_api_exists or even better php_ext_api_exists. I noticed you used this naming style with the callback function. Also, in php_regiser_api size should probably be of type size_t. :-) I really want to reiterate that I am very excited about the possibility of having this functionality. There have been several times where this could have simplified things a bit. Your application looked really good and I'm sure you will have a lot of fun with GSoC. It really is a great program. ~ Graham Kelly On Tue, Mar 31, 2009 at 5:56 AM, Varuna Jayasiri <vpjayasiri@gmail.com>wrote: > 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 > > >