Re: Interested in Abstract Extension API and Dependency Interface

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?


> 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