Re: Re: Interested in Abstract Extension API and Dependency Interface
| From: | shire | Date: | Wed, 01 Apr 2009 22:09:16 +0000 |
| Subject: | Re: Re: Interested in Abstract Extension API and Dependency Interface | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-6282@lists.php.net to get a copy of this message | ||
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 applicationI 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. -shire---->void php_api_set_callback(char *ext_name, int version, void(*callback_func)(void **api, char *ext_name, int version))