Re: Re: Interested in Abstract Extension API and Dependency Interface

Hi, On Wed, Apr 1, 2009 at 12:43 PM, shire <shire@php.net> wrote: > > Hi Varuna, > > Thanks, I think this looks good, I have some input/responses outlined > below. Also some small things: > > Typo, "set o API's" I believe you meant "set of API's". > "When an extension wants to use an API from another extension it can > retrieve it from the set o API’s registered using the extension name and the > version" > Thanks for pointing out :) > > It seems like you've given yourself a lot more development time than > testing time, I usually find I spend more time fixing things than writing > them, but this is up to you of course I don't feel particularly strongly > about it just thought I'd mention it. > What I had in mind was that testing done by my self is part of development time, which I seem to have forgotten to include :P. I have added it now. The time for testing currently shown was to get suggestions for tweaks from the community and to implement them. Now, I have included unit testing in the development time. 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. Varuna Jayasiri wrote: > >> I have not made any changes to whether a structure is passed or >> functions are passed one by one, as I'm still waiting for comments from >> the mentors and other developers regarding this :) >> > > Initially the design was to do this on a function by function basis, > however this created a couple negative affects: > > - Each function would possibly have it's own version. This could be more > confusing than what is really necessary. > - If each function doesn't have it's own version it may not be easy to > group these logically together, possibly creating some more involved code on > the providing extensions side. > - For an API with many functions being exposed, it becomes cumbersome to > fetch many functions. > - A structure would facilitate passing additional information such as > constants, states, etc. (although these could be retrieved by API functions > themselves of course). This could be seen as a good or bad thing, depending > on how it could be abused. (memory pointers etc). > > While I don't feel strongly that we would need a per-function fetch > mechanism, I don't see a huge argument against it if the above can be > resolved. My biggest concern would probably be complicating the function > calls and adding complicated overhead to fetch functions by name. I think > for this to work well it needs to be simple for extensions to provide their > APIs, otherwise it will be unlikely to be implemented and calling extensions > will be forced to link at compile-time. > > > Please point out if there are any improvements to be made :) >> > > One situation that I don't believe has been addressed is the handling of > multiple versions of an API. I'm not convinced this is a problem, but I > want to put it out there for discussion even if we don't add support for it > initially. > > In the case that an extension has provided a large number of API versions, > calling extensions may have a significant number of conditionals testing for > various versions (repeated calls to php_api_exists with different versions). > Also, because we are potentially attaching a single version to the entire > API. A version change may only indicate modification to a single function > which may or not be used by the calling extension. > > I see that these functions can be passed a -1 version to fetch the latest, > so perhaps this suites this purpose in the simplest way possible, however > this is currently lacking a way for the extension to determine the version > that is available once it has the api struct, which I think is necessary > anyways as it can't guarantee it will always be compatible with the latest > API version. A related downside is that this -1 option could open the > possibility for extensions to use it blindly, creating the possibility of > casting it to the wrong API structure version. (as an example the > "Retrieving API" code you used, if the latest version removed the greet > entry from the struct, the subsequent call would be calling undefined > regions of memory, potentially creating some very serious problems). > > > I also want to raise the question of if versions should be singular numeric > versions or something more along the major, minor, patch format ie: 1.0.0.. > I think singular numeric values are simpler to deal with, but want to point > this out in case anyone has opinions/thoughts on any benefits. > > > I'm a little concerned about confusion on when to use php_get_api(). It > seems that the use case may be limited to only fetching an API after module > initialization (is this correct). I would pose the question if this is > necessary, and if it should raise some sort of indicator warning or error > that it shouldn't be used prior to module initialization. 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)) Thanks Varuna > > On Tue, Mar 31, 2009 at 11:57 PM, Graham Kelly <sgkelly4@gmail.com >> In any case what I was describing with APC is that it would be nice >> to have the ability to let extensions expose areas where other >> extensions could extend them. In the example I gave (I only used APC >> because it was the frist thing I could think of) the functionality >> of APC could be extened to support other extensions needs. APC would >> only need to provide a way for this to happen and the extension that >> wants to would supply a function to do this. But as I said, now that >> I think about it this could much more easily be accomplised by >> having the extension just write an API function for this type of >> registration. >> > APC is actually one of the potential use cases for this, I agree that > using the exposed extension API calls to register callbacks is the way to go > rather than adding additional core functionality to do so. > > -shire > > >