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. Comments? ...ant [1] http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions
