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

From: Date: Thu, 02 Apr 2009 02:56:46 +0000
Subject: Re: Re: Interested in Abstract Extension API and Dependency Interface
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-6283@lists.php.net to get a copy of this message
On Thu, Apr 2, 2009 at 3:39 AM, shire <shire@php.net> wrote: > Varuna Jayasiri wrote: > > > I'm not sure if it was the time taken for testing with the help of >> community you are referring to. I'm not certain about how long this >> would take, I just made an rough estimate from the previous experiences >> I've had with other foss communities. >> > > I was speaking more to testing in general, but what you've described I > think is fine. The community testing might take a bit of time, but it seems > like you'll have had a large amount of discussion out of the way before hand > anyways. > > > Yes, it seems that php_get_api() isn't necessary, as all the extensions >> would load the required API's during initialization, rather than calling >> php_get_api each time it wants to access an APIs. >> >> I have removed this function and made a couple of changes to the >> callback function. Please take a look at the modified application >> ---->void php_api_set_callback(char *ext_name, int version, void >> (*callback_func)(void **api, char *ext_name, int version)) >> >> > > I think this looks good. This also brings up questions about > > php_api_exists > php_api_latest_version > > As these are in the same situation, however I feel these may be of use > within the callback so we can probably leave them. I'll pose the question > if you want to leave these as is or combine them into a single function or > if they have enough use to keep them separate. > > > So the API looks pretty straight forward now I think, I wanted to > brainstorm a little about the API structs though. Keeping in mind that > ideally this should be super simple for the providing extension to generate > so we aren't discouraging them form doing it in the first place as it is an > extra step. > > If I have an extension that provides 25 different API versions through the > course of it's life (probably an extreme example for the sake of argument). > We get something like: > > struct api_v1 { > ... > } > struct api_v2 { > ... > } > ... > struct api_v25 { > } > > > and registration: > > php_register_api("provider_ext", 1, &api_v1, sizeof(api_v1)); > php_register_api("provider_ext", 1, &api_v2, sizeof(api_v2)); > ... > php_register_api("provider_ext", 1, &api_v25, sizeof(api_v25)); > > > Any thoughts or suggestions on simplifications we can make here? I don't > want to over-engineer it but this now looks like the moste cumbersome > portion of the project from a user's perspective. > > > To make this complete we should make sure the final result is documented > for users (initially as a wiki or a phpdoc patch I think would be fine), you > mentioned unit tests which I assume you'll be using the existing test > frameworks for(?), also a working example from existing pecl extensions > would be beneficial, mbstring or APC come to mind. Ya some framework such as PhpUnit or SimpleTest can be used I guess. Yes I'll write documentations and some articles on how this could be used. Thanks Varuna > > > -shire >

« previous php.pecl.dev (#6283) next »