On Fri, Feb 27, 2009 at 10:12 AM, Raymond Feng <[email protected]> wrote: > Hi, > > I quickly realized that it's much more complicated than I had thought for > the back compatibility by maintaining two versions of the processors. There > are a few factors involved here: > > 1) We need to copy the OSOA processors into a new package and adjust its > logic to load/save XML to/from the OASIS-based assembly model. It involves > some conversions. > 2) We need to maintain the test cases for the OSOA based processors too. > 3) We will register the two set of processors in the META-INF/services files
To handle 1, 2, and 3, we could start having extension-xml-1.0 and extension-xml-1.1 (or extension-xml-osoa and extension-xml-oasis) and each module would be responsible to register their processors, have test cases, etc. We possibly still going to have to change the package names. > 4) For some of the artifacts such as Intents and PolicySets, do we treat the > OSOA version the same as the OASIS version as now they have different > QNames? > Policy might get complicated once we start restructuring our models and implementation as well, you probably know better the possible issues here as you have your hands on it now. > I'm now starting to think if we should finish the OASIS round first and then > merge the 1.x processors back as a separate effort. > The proposal for 1, 2, and 3 might help going with this approach, which is fine with me. > Thanks, > Raymond > From: Raymond Feng > Sent: Friday, February 27, 2009 9:18 AM > To: [email protected] > Subject: Re: [2.x] [DISCUSS] Backward compatibility > Hi, > > Please see my comments inline. > > Thanks, > Raymond > From: Simon Laws > Sent: Friday, February 27, 2009 6:16 AM > To: tuscany-dev > Subject: [2.x] [DISCUSS] Backward compatibility > 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 > > <rfeng>Good list. There are two primary concerns: XML compatibility and Java > API/Annotation compatibility. XML translation might be much simpler than the > Java API/Annotation. Maybe we should start with XML compatibility > first.</rfeng> > > 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. > > <rfeng>We should have one java model which should be based on OASIS specs. > Then we can see if we can translate the OSOA XML into the OASIS model by the > legacy processors. I don't think the infosets for the two models are > completely compatible. We'll probably see cases that we cannot parse the > OSOA XML into the OASIS model. I more view this as a best-effort.<rfeng> > > 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. > > <rfeng>I would rather keep both OSOA and OASIS XSDs. One thing we can do is > to keep a copy of the OSOA-based processors into a different package name > with osoa. </rfeng> > > Thoughts? > > Regards > > Simon > > [1] http://www.mail-archive.com/[email protected]/msg04724.html > -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
