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

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" 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. 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.

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