On Fri, Feb 27, 2009 at 3:53 PM, ant elder <[email protected]> wrote:
> > > 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 > > Yeah, right. The runtime, certainly the XML processors, have been explicitly designed to be fired up based on the namespace of the XML they are trying to process so it seems a real shame to rip and replace. As for C. I just don't think we know but I agree it's the ideal and, as I say, I wouldn't want to discount it just because we haven't thought about it properly. +1 to doing as much as we can until it gets in the way. Simon
