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 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? 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. 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
