Re: [GSOC] Re: Interested in Abstract Extension API and Dependency Interface

hi,

You may prefer to discuss/ask questions on the pecl developer list
(pecl-dev), there is more readers and you may get more answers. This
list is more about the gsoc process (submissions, issues, etc.)
itself.

Cheers,

On Sat, Mar 28, 2009 at 5:37 PM, Varuna Jayasiri <[email protected]> wrote:
> 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
>>
>



-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org