Re: Re: Interested in Abstract Extension API and Dependency Interface
| From: | Varuna Jayasiri | 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
>