One of the issues that I see from time to time in the open source space is this one. In the commercial world, IBM understood decades ago how important it was to provide backwards compatibility and migration paths. Customers needed to focus their resources in a forward way, not re-doing that which had already been done.
The litany of vendors who have also made this mistake can be found in the graveyards of many companies and open source projects. DEC's demise occurred in part because they didn't do that in their 36-bit processor world. Microsoft keeps making the same mistake with some of their products (an amazing number of programs still require VB6, for example), and it hurts them more than they seem to realize. The deprecation technique is a very good way of dealing with the issue. Don't make that same mistake. Unless you have good solid information that an overwhelming number of your customers/participants are OK with breaking backwards-compatibility, don't. I think Paul is right on the button. JRJ -----Original Message----- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Sunday, November 07, 2010 9:10 PM To: dev@synapse.apache.org Cc: u...@synapse.apache.org Subject: Re: Synapse configuration namespace Since we were planing for a 2.0 release, I thought it is OK to do backwards incompatible changes and document them properly. Well we have some changes in the API as well, which will affect the existing mediators and so forth. Do you think we should keep the ability to run the 1.x mediators as it is on the 2.0 as well. I would like to hear users and other dev feedback on this... please raise your view on this. Thanks, Ruwan On Mon, Nov 8, 2010 at 6:41 AM, Hiranya Jayathilaka <hiranya...@gmail.com>wrote: > Hi Paul, > > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pzf...@gmail.com> wrote: > > I don't see the point in changing the namespace unless there is an > > incompatibility at the core. We wrote the model to be very flexible. > > > > Having a migration XSLT is great, but it seems to me a "fix" for > > something that is tricky. Also, we spent a lot of effort on backwards > > compatibility: for example, I would have loved to have added new > > methods to the messagecontext, but put them into helper classes to > > avoid breaking existing mediators. > > > > At some point I think we will need to change the config radically, and > > that is the time to make a breaking change. > > > > I propose we make the code read the old config as well as the new (as > > much as possible) and print a deprecation statement. We should be able > > to always write the new config, so that users serializing their config > > will move to the new one. > > I don't think we can support both namespaces at once without making a > huge amount of changes/additions to the code. Axiom doesn't give too > many options in this space. We have all the namespaces, local names > and QNames defined as global constants in the code. > > So how about this? By default we expect configurations to have the new > namespace. But if somebody wants to load a configuration with the old > namespace, he has to first set a special property in > synapse.properties or as a system property. > > eg: -DuseOldNamespace=true > > We can easily support this model but even that is not perfect: > 1. It is global - Once set it will affect each and every artifact > loaded into Synapse > 2. It will affect the serialization - If the property is set, > configuration will be serialized with the old namespace > > Thanks, > Hiranya > > > > > Paul > > > > On Sat, Oct 2, 2010 at 2:01 PM, Ruwan Linton <ruwan.lin...@gmail.com> > wrote: > >> Sanjiva, > >> We have a complete migration XSLT (it is not just the namespace, we have > a > >> few configuration language changes as well), what we could do is that, > if we > >> find the namespace to be the 1.x while tying to build the configuration > >> model, we could first run the script and update the synapse > configuration > >> after backing up the existing one and continue loading synapse. > >> WDYT? > >> Thanks, > >> Ruwan > >> > >> On Sat, Oct 2, 2010 at 10:21 AM, Sanjiva Weerawarana < > sanj...@opensource.lk> > >> wrote: > >>> > >>> I realize this is a bit of a late response :(. > >>> This change will break all existing users. How about at least > supporting > >>> both namespaces? > >>> (Maybe this is too late now for the release ... in which case there's > no > >>> point doing it later.) > >>> Sanjiva. > >>> On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton <ruwan.lin...@gmail.com > > > >>> wrote: > >>>> > >>>> Folks, > >>>> > >>>> We have been using the http://ws.apache.org/ns/synapse as the synapse > >>>> configuration namespace, since synapse was graduated on to the WS > project > >>>> and we didn't want to introduce a configuration incompatibility > because of > >>>> becoming a new TLP, and with the new 2.0 release planned to be out, I > am > >>>> planning to change the synapse configuration namespace to a more > meaning > >>>> full namespace; > >>>> > >>>> http://synapse.apache.org/ns/2010/04/configuration > >>>> > >>>> Provided that the migration tool will be there this change should be > OK > >>>> with the 2.0 release. > >>>> > >>>> Thoughts?? > >>>> > >>>> Thanks, > >>>> Ruwan > >>>> > >>>> -- > >>>> Ruwan Linton > >>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb > >>>> WSO2 Inc.; http://wso2.org > >>>> email: ru...@wso2.com; cell: +94 77 341 3097 > >>>> blog: http://ruwansblog.blogspot.com > >>> > >>> > >>> > >>> -- > >>> Sanjiva Weerawarana, Ph.D. > >>> Founder, Director & Chief Scientist; Lanka Software Foundation; > >>> http://www.opensource.lk/ > >>> Founder, Chairman & CEO; WSO2; http://wso2.com/ > >>> Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ > >>> Member; Apache Software Foundation; http://www.apache.org/ > >>> Member; Sahana Software Foundation; http://www.sahanafoundation.org/ > >>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > >>> > >>> Blog: http://sanjiva.weerawarana.org/ > >> > >> > >> > >> -- > >> Ruwan Linton > >> Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb > >> WSO2 Inc.; http://wso2.org > >> > >> Lean . Enterprise . Middleware > >> > >> phone: +1 408 754 7388 ext 51789 > >> email: ru...@wso2.com; cell: +94 77 341 3097 > >> blog: http://blog.ruwan.org > >> linkedin: http://www.linkedin.com/in/ruwanlinton > >> google: http://www.google.com/profiles/ruwan.linton > >> tweet: http://twitter.com/ruwanlinton > >> > > > > > > > > -- > > Paul Fremantle > > Co-Founder and CTO, WSO2 > > Apache Synapse PMC Chair > > OASIS WS-RX TC Co-chair > > > > blog: http://pzf.fremantle.org > > p...@wso2.com > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > > For additional commands, e-mail: dev-h...@synapse.apache.org > > > > > > > > -- > Hiranya Jayathilaka > Senior Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > -- Ruwan Linton Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
