Re: Interested in Abstract Extension API and Dependency Interface

Hi, On Fri, Mar 27, 2009 at 11:46 PM, shire <shire@php.net> 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