On 3/29/07, ant elder <[EMAIL PROTECTED]> wrote:
On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: <snip/> One reason the SPI module is so large is that it does define many the > interfaces for the components in you diagram. I think there is room > for a reorganization there to clarify the usage of those interfaces. > I would propose we start with that ... There have been several emails now which I think show some agreement that we can do some SPI refactoring. Here's something that could be a start of this work: One area is the extension SPI, on our architecture diagram [1] thats the "Extensions" box at the top right. In the past we've had a lot of problems with extensions continually getting broken as the SPIs keep changing. This has made maintaining extensions to be in a working state a big job and it has led to some donated extension just being abandoned. One of the reasons for this is that the SPIs more reflect the requirements of the Tuscany runtime than the requirements of the extension being contributed. For example, a container extension needs to enable creating, initializing, invoking and destroying a component, along with exposing the components services, references and properties. Those things have remained pretty constant even though the SCA specs and Tuscany runtime and SPI have undergone significant changes. I think we should be able to create SPIs for these type of functions which clearly represent the requirements of a particular extension type, and that doing this would go along way to making things more stable. All this code is there in the current SPI so its mainly just a mater of refactoring parts out into separate bits with clearly defined function and adding adapter code so the runtime can use them. You can even envisage that if this is successful it could define a runtime extension SPI for all the extensible areas of SCA assembly which could eventually be standardized to provide portable SCA extensions in a way similar to JBI. What do people think, is this worth looking at? If so I'd like to make an attempt at doing it for bindings and components using the Axis2 binding and script container as guinea pigs. This should be pretty transparent to the rest of the kernel as other than the adapter code it could all be separate modules.
I mentioned on the release discussion thread that I'd bring this thread up again. The new trunk code has made things better in the SPI area but I think there's still a lot that could be improved (IMHO). The sort of thing i was thinking about was coming up with runtime support and an spi package for each extension time that made it clear what all the methods needed to be implemented for at least minimum functionality. For example, for an implementation extension minimum functionality would support services, references and properties (at least simple type properties anyway), correctly merging introspected and sidefile defined component type info, component instance life cycle and scope, and the correct invocation semantics for things like pass-by-value support. And do all that in a way where the majority of code is done generically in the runtime instead of the extension either not supporting some of those things or just copying chunks of code from other extensions to get the support. Do others agree this is something we should try to do for the next release? If so I thought about starting with a new modules for implementation-spi, binding-spi etc to avoid changing the existing runtime code for now. And I'd like to start on the implementation-spi one with the goal being to eventually move all the implementation extensions to use it - so crud, java and script. WDYT? ...ant
