On Fri, Feb 27, 2009 at 6:12 PM, 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 > 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. > > The problem with just focusing on OASIS for now and ignoring backward compatibility is that it might make more work and be harder to do in the long run, or we may end up just never getting around to it later. I think thats what the mail initiating this thread was saying. Backward compatibility is important. Being incompatibile makes unnecessary work for our users, they'll find applications breaking frustrating, and it may end up loosing us users when they decide instead of spending the time to upgrade to Tuscany 2.x they might as well change to use new framework xxx instead. I don't think 2.x backward compatibility needs to be perfect, as was said earlier a best-effort approach will do. So things like saving XML, or supporting policy variations seem less important as they're not used that much in 1.x. All we really need is for common 1.x applications to continue to run unchanged in 2.x. Take some of our basic samples from 1.x like the calculator and helloworld samples and ideally they'd run unchanged in 2.x. I don't think achieving that will not be so hard, I've done some SVN diffs of 1.x and 2.x and th changes aren't that big. Searching all the modules for "import org.oasisopen.sca" shows there are not that many hits, most are just for things like ServiceRuntimeException, and lots of others would be easy to fix with trivial changes to check for either annotation. Most of the extension schemas are very similar, the JMS binding has some attributes changed like "name" to "jndiName" which would be easy to code compatibility for. A diff of the calculator sample from 1.x to 2.x shows trivial changes to the Tuscany APIs that it would be easy for us to provide deprecated methods for so the samples continue to run unchanged. So unless someone can give a concrete example of something that would be really hard to make work then i think we should try do this for now. ...ant
