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

Hi, Thank you very much for the comments :) On Tue, Mar 31, 2009 at 8:01 PM, Graham Kelly <sgkelly4@gmail.com> wrote: > Hey, > > Overall I think your application looked really good. Thanks :) > > 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. > Yes, this seems to be a better approach. So with this method, would the function prototypes be declared on the caller extension. > 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. :-) Yes these should be changed :P. I should have proofread the application more carefully :P. > > > 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. > Thanks > > ~ Graham Kelly > Varuna > > > 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 >> > >> > >