RE: Synapse configuration namespace

2010-11-22 Thread Jaeger, Jay - DOT
Jay Jaeger -Original Message- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Sunday, November 21, 2010 10:38 PM To: u...@synapse.apache.org Cc: dev@synapse.apache.org Subject: Re: Synapse configuration namespace OK We need to do the 2.0.0 release ASAP, it has been dragging wa

Re: Synapse configuration namespace

2010-11-22 Thread Ruwan Linton
actor in your decision. > > Jay Jaeger > > -Original Message- > From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] > Sent: Sunday, November 21, 2010 10:38 PM > To: u...@synapse.apache.org > Cc: dev@synapse.apache.org > Subject: Re: Synapse configuration namespace > &

Re: Synapse configuration namespace

2010-11-21 Thread Hiranya Jayathilaka
On Mon, Nov 22, 2010 at 10:07 AM, Ruwan Linton wrote: > OK > > We need to do the 2.0.0 release ASAP, it has been dragging way too much, and > I don't want to delay it because of a namespace change and do not want to > call another vote for this. Let me take your votes from this thread and try

Re: Synapse configuration namespace

2010-11-21 Thread Ruwan Linton
OK We need to do the 2.0.0 release ASAP, it has been dragging way too much, and I don't want to delay it because of a namespace change and do not want to call another vote for this. Let me take your votes from this thread and try to summarize the decision on this. If I have interpreted this t

Re: Synapse configuration namespace

2010-11-21 Thread Sanjiva Weerawarana
On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric wrote: > Well, I think I have to agree with Sanjiva’s statement about the meaning > of namespaces for an end user. I also do not know many people really caring > about namespaces as long as those namespaces are not causing any troubles. > Maybe one sh

RE: Synapse configuration namespace

2010-11-21 Thread Hubert, Eric
...@gmail.com] Sent: Sunday, November 21, 2010 3:25 PM To: dev@synapse.apache.org Cc: u...@synapse.apache.org Subject: Re: Synapse configuration namespace I'm +1 for a namespace change if we have changed the semantics of the synapse configuration language at a broader level. But since we haven&#

Re: Synapse configuration namespace

2010-11-21 Thread Supun Kamburugamuva
I'm +1 for a namespace change if we have changed the semantics of the synapse configuration language at a broader level. But since we haven't done any major change to the configuration language im 0 on this. So my opinion solely depend on what users will think and how they will get affected. Thank

Re: Synapse configuration namespace

2010-11-20 Thread Ruwan Linton
I found more incompatible changes :-( https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12934217 I do not understand why you are opposing to changing the namespace with 2.0 release, while we h

Re: Synapse configuration namespace

2010-11-20 Thread Sanjiva Weerawarana
On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton wrote: > Also, in general using namespaces to version XML schemas is generally >> considered bad practice. >> > > I don't think we are doing a versioning of the synapse configuration schema > with the namespace, anyway most of > Then what are you achi

Re: Synapse configuration namespace

2010-11-20 Thread Ruwan Linton
ve. Although I'm certainly not happy having to adjust >>> mediator code before moving the next major version I'd rather take this >>> effort, than having to help hunting bugs in overly complicated code >>> resulting from trying to avoid incompatibilities while add

Re: Synapse configuration namespace

2010-11-20 Thread Sanjiva Weerawarana
void incompatibilities while adding new major >> features. >> >> Regards, >>Eric >> >> >> >> > -Original Message- >> > From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] >> > Sent: Monday, November 08, 2010 4

Re: Synapse configuration namespace

2010-11-20 Thread Ruwan Linton
o help hunting bugs in overly complicated code > resulting from trying to avoid incompatibilities while adding new major > features. > > Regards, >Eric > > > > > -Original Message- > > From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] > > Sent: Monday, Nove

RE: Synapse configuration namespace

2010-11-08 Thread Jaeger, Jay - DOT
pse.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 a

Re: Synapse configuration namespace

2010-11-07 Thread Ruwan Linton
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 i

Re: Synapse configuration namespace

2010-11-07 Thread Hiranya Jayathilaka
Hi Paul, On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle 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 trick

Re: Synapse configuration namespace

2010-11-07 Thread Paul Fremantle
PS My apologies for not bringing this up earlier :-( On Sun, Nov 7, 2010 at 11:20 PM, Paul Fremantle 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 seem

Re: Synapse configuration namespace

2010-11-07 Thread Paul Fremantle
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,

Re: Synapse configuration namespace

2010-10-02 Thread Ruwan Linton
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 confi

Re: Synapse configuration namespace

2010-10-01 Thread Sanjiva Weerawarana
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 wrote:

Re: Synapse configuration namespace

2010-04-28 Thread Ruwan Linton
I think I have done that as well Rajika. Please take an svn update and see. Thanks, Ruwan On Wed, Apr 28, 2010 at 6:58 PM, Rajika Kumarasiri wrote: > We need to update all the samples as well. > > Rajika > > > On Tue, Apr 27, 2010 at 2:55 PM, Ruwan Linton wrote: > >> Relevant changes for this n

Re: Synapse configuration namespace

2010-04-28 Thread Rajika Kumarasiri
We need to update all the samples as well. Rajika On Tue, Apr 27, 2010 at 2:55 PM, Ruwan Linton wrote: > Relevant changes for this namespace change has been done on the trunk. > > Thanks, > Ruwan > > > On Tue, Apr 27, 2010 at 10:01 AM, Hiranya Jayathilaka < > hiranya...@gmail.com> wrote: > >> >>

Re: Synapse configuration namespace

2010-04-27 Thread Ruwan Linton
Relevant changes for this namespace change has been done on the trunk. Thanks, Ruwan On Tue, Apr 27, 2010 at 10:01 AM, Hiranya Jayathilaka wrote: > > > On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton wrote: > >> Folks, >> >> We have been using the http://ws.apache.org/ns/synapse as the synapse >>

Re: Synapse configuration namespace

2010-04-26 Thread Hiranya Jayathilaka
On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton 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 > becomi