Hi, I have shared a recent experience in this regard with comments inline.
Thanks - Venkat On 4/20/07, ant elder < [EMAIL PROTECTED]> wrote:
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.
I entirely agree with this. I remember that one of the 'ceremonious' things we used to do in the old code base to implement an extension was to copy over quite a bit of code from a existing one. I guess we must avoid that this time around. I'd really like to have the .componentType info gathering done in the core. The only thing that might get specific to implementation extensions in this is the URI for the .componentType file. i.e. for java-implementations this is derived from the 'class' field of implementaion .java and for script-impl this is derived from the 'scriptname'. I guess, getting this URI can be done by adding one more SPI method 'getComponentTypeURI' like the way we have 'getArtifactType' for each implementation. The other case that I feel could be a part of the core itself is the PropertyValue ObjectFactory and the Databinding support that it uses. This can again be a part of the core and there could just about an SPI method such as 'setProperty(name, value)' that could be implemented by implementation extensions. If there are some specific transformers that the implementation needs then those alone can be contributed by the implementation. 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?
+1. I'd say this probably is the right time to fix this because our primary goal presently is stabilization and better consumability for users and extension developers. If we fix this now, its going to be encouraging for extensions developers and also a lot of code refactoring work in the future. So if the community feels the same then I'd be happy to help you out in this effort. Thanks - Venkat ...ant
