Re: Interested in Abstract Extension API and Dependency Interface

Hi Shire,

On Sat, Mar 28, 2009 at 3:00 PM, Varuna Jayasiri <[email protected]>wrote:

> Hi,
>
> On Fri, Mar 27, 2009 at 11:46 PM, shire <[email protected]> wrote:
>
>>
>> Hi Varuna,
>>
>> Varuna Jayasiri wrote:
>>
>>> Hi,
>>>
>>> I went through most of the tutorials and presentations you've listed,
>>> and they were very helpful :). I coded a couple of simple extensions to
>>> get some hands on experience.
>>>
>>
>>  I have started drafting the application form and will publish it soon,
>>> so that I can get your comments for improvements and adjustments.
>>>
>>
>> Good to hear, looking forward to seeing it.
>>
>>
>>  Also, there's a small thing which I want to clarify about the API in the
>>> initial design in the gsoc ideas page. What are fetch and store
>>> functions?
>>>
>>
>> Sorry this example probably isn't entirely clear, I'll try to add some
>> more detail here so there's no confusion.  fetch() and store() are simply
>> API functions that could be anything that the extension wants to expose or
>> use.  I used fetch/store as this would apply to the APC extension which
>> fetches and stores entries from cache.  This could easily be any
>> functionality as defined on an extension specific basis such as encrypt,
>> copy, send, query, etc.
>>
>
> Sorry this isn't still  clear for me. I'm really sorry if I'm asking stupid
> questions :P :P
>
> Is the api structure (extension_api_t) like, for instance,
> struct extension_api_t
> {
> int version;
> EXTENSION_API_FUNCTION fetch, store;
> }
> If so, how to add functions like copy, send, query?
>

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.

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
e.g.
#ifdef HAVE_MYEXTENSION
struct extension_api_t *api;
#else
zend_error(E_WARNING, "myextension is not loaded or available, disabling
feature");
#endif

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);

Thank you
 Varuna


>
>
>> Let me know if this still isn't clear as this is a pretty important piece
>> to understand for this project.
>>
>>
>>  And how should  various other functions be registered. Is it
>>> ok if we you use some thing like,
>>> register_function(&api, str_function_name, function_pointer) for
>>> registering and
>>> call_api_function(api, "extension_function", parameters) to call those
>>> api_functions?
>>>
>>
>> These probably will make more sense once you understand the previous
>> question more, but these functions should register multiple functions at
>> once rather than individual functions.  This will be done by creating a
>> structure for the extension (in this case called api).  This contains
>> multiple pointers to functions such as fetch, store, or anything else that
>> needs to be exposed.  So in the above by passing &api, you're in fact
>> passing many functions to be registered.
>>
>> In regards to the call_api_function you've prototyped above, I want to
>> note that an advantage of being able to retrieve this as a structure
>> containing multiple file pointers is that you can call functions without the
>> overhead of going through a wrapper function.  For example intsead of
>> calling this call_api_function as you've listed above, it is much for
>> efficient to grab a structure and call it with something like
>> 'some_api.some_func()', especially if done in a loop.
>>
>> Again, this is what we came up with, please continue to provide suggested
>> alternatives if you see room for improvement or if it will help you
>> understand the design considerations involved.
>>
>
> Thank you :)
>
>
>>
>> -shire
>>
>
>
> Thank you
>  Varuna
>