On Fri, Feb 27, 2009 at 2:16 PM, Simon Laws <[email protected]>wrote:
> We recently moved over to the OASIS package names [1] and I notice commits > to change the schema yesterday. So I want to discuss the backward > compatibility issue again. If we have aspirations to support any kind of > backward compatibility then we need to think about it now a bit otherwise > we'll make life difficult for ourselves later on > > So what does backward compatibility mean? There are a range of answers. For > example, > > A/ None - SCA 1.0 and SCA 1.1 composites must run on completely separate > 1.x and 2.x Tuscany runtimes. Any interaction is through remote bindings > B/ Shared domain - SCA 1.0 and SCA 1.1 composites can be contributed to the > same domain but spec specific node/runtimes are required to actually run > them. Binding. sca is compatible though. > C/ Shared runtime - SCA 1.0 and SCA 1.1 composites can be contributed to > the same node/untimes > > In my opinion we should do at least B and give some though to the > implications of C to either discount it or address it. > > I think the implication of B is that the assembly model is shared between > SCA 1.0 and SCA 1.1. I don't want to blow progress of course and I still > agree with Ant that we can bring backward compatibility on line a little > later. However if we do just rip and replace SCA 1.0 for SCA 1.1 then it > makes this later effort more difficult that it need be. > > This probably just comes down to simple things. It's tempting to just > replace all the xsd's and fix up the processors to take account of them. But > unless we change the processor package names and/or class names then it > makes it harder to bring the SCA1.1 processors back in when we want to run > both in the domain. > > Thoughts? > > Regards > > Simon > > [1] http://www.mail-archive.com/[email protected]/msg04724.html > That C/ above is the ideal isn't it? So what if we just say we will do that until we find some blocking issue? OTTOMH I can't think of a blocking issue, can anyone? If not then its just implementation detail - we need scdl processors for each version, the SCA API for bother versions, and in the Tuscany code things like everywhere it looks for an SCA annotation it needs to check in both old and new packages. As we implement it we may come across something that impossible to do in the one runtime so if/when that happens we'd either need to abandon the backward compatibility effort or else document the case and say if thats an issue to an application then it needs to stay using the 1.x code. ...ant
