You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Paul Fremantle <pz...@gmail.com> on 2008/06/12 03:15:54 UTC
[DISCUSS] Mercury Proposal
I have posted a proposal here:
http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
Please edit, improve, or discuss.... I put this in the wiki so that it
could be modified.
Paul
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Glen,
*** My 2 cents, YMMV. This is not an intention to start a flame fest. It's a personal opinion ***
FWIW, I am quite tired and fed up of folks who don't actually do the work push things around and nothing ever happens
after a so called decision is made. Case in point, remember the discussion on transports in Axis2/Synapse.
So, if this is what Amila wants to do, am ok. If someone wants to join in, more the merrier and they can actually decide
what to do, when and how. I'd personally like to get this going and get out of the way of the person(s) executing.
So, if the incubator folks are ok and we are legally covered. My personal view is to just get it going and get out of
the way.
thanks,
dims
Paul Fremantle wrote:
| Glen. I didn't think there was any consensus from the previous
| discussion (does the word dissensus exist?) :)
|
| I am actually pretty happy to do either, I think each approach has +s and -s.
|
| On the side of starting from the Mercury codebase, Amila has got it to
| a point where it satisfies the 1.0 spec, including Replay.
| On the other hand, Mercury doesn't yet implement 1.1 or
| MakeConnection, and also it doesn't support transactions yet, so there
| are some fairly large aspects still to be coded. And starting afresh
| might well get more involvement from the wider community which I think
| has been the main pushback on this proposal so far.
|
| I guess one open question is - who is willing to put in the effort to
| work on this?! If it's just Amila, then starting afresh won't be much
| benefit, because he will be happier to keep working from the code he
| has already built. If there is a wider set of people willing to put in
| effort, then starting afresh might have significant benefits.
|
| Paul
|
| On Thu, Jun 12, 2008 at 2:53 AM, Glen Daniels <gl...@thoughtcraft.com> wrote:
|> Hi Paul:
|>
|> Paul Fremantle wrote:
|>> I have posted a proposal here:
|>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
|>>
|>> Please edit, improve, or discuss.... I put this in the wiki so that it
|>> could be modified.
|> Hm... I thought where we'd ended up discussion-wise was that we would get
|> the Mercury code granted to Apache so that it could be examined / learned
|> from / experimented with, but that we would aim to create a "third way" as
|> the next step for both projects.
|>
|> In other words, the actual work that happens to make the new "unified" RM
|> implementation (whatever it ends up being called) would start with a clean
|> slate and take whatever it can from both Sandesha and Mercury, with the goal
|> of making sure that all the active developers are involved and empowered.
|> Did I understand that right?
|>
|> Your proposal makes it sound rather like we're going to just start from the
|> existing Mercury code and go from there.
|>
|> --Glen
|>
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIURzngNg6eWEDv1kRAtIOAKC/nqAg1CZPcx08WhJsALUHbwPSuwCg+g5W
0HR9t8e7Es4he0UZOjGZbv4=
=DM6b
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Glen,
*** My 2 cents, YMMV. This is not an intention to start a flame fest. It's a personal opinion ***
FWIW, I am quite tired and fed up of folks who don't actually do the work push things around and nothing ever happens
after a so called decision is made. Case in point, remember the discussion on transports in Axis2/Synapse.
So, if this is what Amila wants to do, am ok. If someone wants to join in, more the merrier and they can actually decide
what to do, when and how. I'd personally like to get this going and get out of the way of the person(s) executing.
So, if the incubator folks are ok and we are legally covered. My personal view is to just get it going and get out of
the way.
thanks,
dims
Paul Fremantle wrote:
| Glen. I didn't think there was any consensus from the previous
| discussion (does the word dissensus exist?) :)
|
| I am actually pretty happy to do either, I think each approach has +s and -s.
|
| On the side of starting from the Mercury codebase, Amila has got it to
| a point where it satisfies the 1.0 spec, including Replay.
| On the other hand, Mercury doesn't yet implement 1.1 or
| MakeConnection, and also it doesn't support transactions yet, so there
| are some fairly large aspects still to be coded. And starting afresh
| might well get more involvement from the wider community which I think
| has been the main pushback on this proposal so far.
|
| I guess one open question is - who is willing to put in the effort to
| work on this?! If it's just Amila, then starting afresh won't be much
| benefit, because he will be happier to keep working from the code he
| has already built. If there is a wider set of people willing to put in
| effort, then starting afresh might have significant benefits.
|
| Paul
|
| On Thu, Jun 12, 2008 at 2:53 AM, Glen Daniels <gl...@thoughtcraft.com> wrote:
|> Hi Paul:
|>
|> Paul Fremantle wrote:
|>> I have posted a proposal here:
|>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
|>>
|>> Please edit, improve, or discuss.... I put this in the wiki so that it
|>> could be modified.
|> Hm... I thought where we'd ended up discussion-wise was that we would get
|> the Mercury code granted to Apache so that it could be examined / learned
|> from / experimented with, but that we would aim to create a "third way" as
|> the next step for both projects.
|>
|> In other words, the actual work that happens to make the new "unified" RM
|> implementation (whatever it ends up being called) would start with a clean
|> slate and take whatever it can from both Sandesha and Mercury, with the goal
|> of making sure that all the active developers are involved and empowered.
|> Did I understand that right?
|>
|> Your proposal makes it sound rather like we're going to just start from the
|> existing Mercury code and go from there.
|>
|> --Glen
|>
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIURzngNg6eWEDv1kRAtIOAKC/nqAg1CZPcx08WhJsALUHbwPSuwCg+g5W
0HR9t8e7Es4he0UZOjGZbv4=
=DM6b
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sat, Jun 14, 2008 at 12:43 AM, Chamikara Jayalath <ch...@gmail.com>
wrote:
> We actually considered this idea in the early phases of Sandesha2. After
> some discussions we thought of going for a Axis2 based one so that we can
> use all the features that are readily available with Axis2. These included
> the context hierarchy, pause/resume functionality, Messages Receivers, AXIOM
> etc.
I agree with Chamikara.
As I have mention earlier Mercury has two parts. The real implementation of
Mercury/Sandesha2 or any RM implementation depends lot about Axis2
architecture and all the things Chamikara has mentioned. Therefore writting
a Common implementation will be a very complex one. For an example it always
depends on the MessageContext and its properties.
However As I showed earlier, The state machine model (given in simulator)
does not depends on the Axis2. So someone can implement that on top of CXF.
thanks,
Amila.
>
>
> Chamikara
>
>
>
> On Fri, Jun 13, 2008 at 1:15 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>>
>> Just FYI: I'm also quite interested in the idea of a "generic" RM engine
>> that could be plugged in to various stacks/providers. Things like WSS4J
>> and Neethi have been a big help to CXF (and probably others) specifically
>> because they were "generic" enough to be used outside of Axis. In the
>> case of WSS4J, it has actually helped the WSS4J community as developers
>> working on CXF stuff have started contributing to WSS4J as well. Fred
>> Dushin is now a committer on WSS4J specifically due to work integrating it
>> with CXF. Sandesha could potentially benefit similarly if it can become
>> generic enough to not be considered "just a RM plugin to Axis 2".
>> Basically, this could be an opportunity to expand the Sandesha community,
>> and that's a good thing.
>>
>> Dan
>>
>>
>>
>>
>> pzfreo wrote:
>> >
>> > David
>> >
>> > I want to make it clear that I'm *strongly* hoping that there will be
>> > greater involvement than just one person.
>> >
>> > I also *really* like the idea of building an RM implementation that
>> > has a core model that is not dependent around a specific stack (Axis2,
>> > CXF). I have always believed that there is a space for a really stable
>> > and performant WSRM messaging engine and the Sandesha model - where
>> > the stack is in control and the messaging engine is "just" a set of
>> > handlers just doesn't feel to me like it can compete with a pure
>> > messaging option like ActiveMQ or QPid. So in many ways, starting from
>> > WSRM and treating the problem as "how to build a messaging engine that
>> > also happens to be able to fit into Axis2" would be very interesting
>> > to me.
>> >
>> > I am actually not against having an incubator proposal. The only
>> > challenge with the Incubator is that:
>> > 1) the incubator is fundamentally designed to bootstrap new
>> > communities. If there is an existing community already then it doesn't
>> > necessarily work. I would rather have this discussion on sandesha-dev
>> > than have to somehow encourage everyone from sandesha-dev to start
>> > paying attention to a new list.
>> > 2) The incubator is also about how to get non-Apache members involved.
>> > So far everyone interested in this is already a committer in Apache.
>> > So in fact, labs.apache.org is more appropriate.
>> > 3) The incubator is a hassle. Its a hassle for good reasons and I
>> > strongly support it. But if you don't need that hassle, then you
>> > shouldn't take it!
>> >
>> > How would a design that works across both CXF and Axis2 work? Its an
>> > intriguing idea.
>> >
>> > Paul
>> >
>> >
>> >
>> > On Thu, Jun 12, 2008 at 5:02 PM, David Illsley <da...@gmail.com>
>> > wrote:
>> >> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com>
>> wrote:
>> >>> Glen. I didn't think there was any consensus from the previous
>> >>> discussion (does the word dissensus exist?) :)
>> >>>
>> >>> I am actually pretty happy to do either, I think each approach has +s
>> >>> and -s.
>> >>>
>> >>> On the side of starting from the Mercury codebase, Amila has got it to
>> >>> a point where it satisfies the 1.0 spec, including Replay.
>> >>> On the other hand, Mercury doesn't yet implement 1.1 or
>> >>> MakeConnection, and also it doesn't support transactions yet, so there
>> >>> are some fairly large aspects still to be coded. And starting afresh
>> >>> might well get more involvement from the wider community which I think
>> >>> has been the main pushback on this proposal so far.
>> >>
>> >> Clearly new code developed here will have far fewer legal issues (e.g.
>> >> the submitted Mercury has a hard LGPL dependency which would need
>> >> ironed out), and would hopefully have a cleaner state machine model -
>> >> the Mercury one seems to have compromised for reasons which are pretty
>> >> opaque.
>> >>
>> >>> I guess one open question is - who is willing to put in the effort to
>> >>> work on this?! If it's just Amila, then starting afresh won't be much
>> >>> benefit, because he will be happier to keep working from the code he
>> >>> has already built.
>> >>
>> >> I'd certainly be interested in being involved in a new codebase, but
>> >> the amount of time I'd have to devote to it would be limited. If it's
>> >> just Amila, then my "Apache Way Sense" tingles to suggest that this
>> >> isn't really going anywhere in Apache, and probably shouldn't.
>> >>
>> >> These 2 questions (legal and community) are some of the reasons why
>> >> the Incubator exists, and sort of points me back in that direction.
>> >>
>> >> David
>> >>
>> >> P.S. In writing this, it occurred to me that trying to write a common
>> >> WS-RM kernel that could be used with CXF and Axis2 might be a good
>> >> target, and that too, might point to the Incubator to help build a
>> >> broader community (not a fully formed thought though)
>> >>
>> >> P.P.S. I really like "dissensus"
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Paul Fremantle
>> > Co-Founder and CTO, WSO2
>> > Apache Synapse PMC Chair
>> > OASIS WS-RX TC Co-chair
>> >
>> > blog: http://pzf.fremantle.org
>> > paul@wso2.com
>> >
>> > "Oxygenating the Web Service Platform", www.wso2.com
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17828246.html
>> Sent from the Apache Sandesha mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [DISCUSS] Mercury Proposal
Posted by Chamikara Jayalath <ch...@gmail.com>.
If we can come up with a good set of interfaces with good compromises I
would completely agree. I wasn't talking about CXF or any specific
implementation.
BTW this was three years back. So things should be different now. :-)
Chamikara
On Fri, Jun 13, 2008 at 3:20 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>
>
> Pretty much any stack is going to have those same features readily
> available. If Sandesha defined interfaces it needed, then any
> implementation could provide implementations for those interfaces that
> calls
> back into that implementations versions. It shouldn't be a big deal.
>
> Basically, if there are thoughts to re-architect things based on the
> Mercury
> code, it's something that would be good to consider from a technical
> viewpoint, but, more importantly, from a community view point as well.
>
> Remember, at Apache, it's community over code. :-)
>
> Dan
>
>
>
> Chamikara Jayalath wrote:
> >
> > We actually considered this idea in the early phases of Sandesha2. After
> > some discussions we thought of going for a Axis2 based one so that we can
> > use all the features that are readily available with Axis2. These
> included
> > the context hierarchy, pause/resume functionality, Messages Receivers,
> > AXIOM
> > etc.
> >
> > Chamikara
> >
> >
> > On Fri, Jun 13, 2008 at 1:15 PM, Daniel Kulp <dk...@apache.org> wrote:
> >
> >>
> >>
> >> Just FYI: I'm also quite interested in the idea of a "generic" RM
> engine
> >> that could be plugged in to various stacks/providers. Things like
> WSS4J
> >> and Neethi have been a big help to CXF (and probably others)
> specifically
> >> because they were "generic" enough to be used outside of Axis. In
> the
> >> case of WSS4J, it has actually helped the WSS4J community as developers
> >> working on CXF stuff have started contributing to WSS4J as well. Fred
> >> Dushin is now a committer on WSS4J specifically due to work integrating
> >> it
> >> with CXF. Sandesha could potentially benefit similarly if it can become
> >> generic enough to not be considered "just a RM plugin to Axis 2".
> >> Basically, this could be an opportunity to expand the Sandesha
> community,
> >> and that's a good thing.
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >> pzfreo wrote:
> >> >
> >> > David
> >> >
> >> > I want to make it clear that I'm *strongly* hoping that there will be
> >> > greater involvement than just one person.
> >> >
> >> > I also *really* like the idea of building an RM implementation that
> >> > has a core model that is not dependent around a specific stack (Axis2,
> >> > CXF). I have always believed that there is a space for a really stable
> >> > and performant WSRM messaging engine and the Sandesha model - where
> >> > the stack is in control and the messaging engine is "just" a set of
> >> > handlers just doesn't feel to me like it can compete with a pure
> >> > messaging option like ActiveMQ or QPid. So in many ways, starting from
> >> > WSRM and treating the problem as "how to build a messaging engine that
> >> > also happens to be able to fit into Axis2" would be very interesting
> >> > to me.
> >> >
> >> > I am actually not against having an incubator proposal. The only
> >> > challenge with the Incubator is that:
> >> > 1) the incubator is fundamentally designed to bootstrap new
> >> > communities. If there is an existing community already then it doesn't
> >> > necessarily work. I would rather have this discussion on sandesha-dev
> >> > than have to somehow encourage everyone from sandesha-dev to start
> >> > paying attention to a new list.
> >> > 2) The incubator is also about how to get non-Apache members involved.
> >> > So far everyone interested in this is already a committer in Apache.
> >> > So in fact, labs.apache.org is more appropriate.
> >> > 3) The incubator is a hassle. Its a hassle for good reasons and I
> >> > strongly support it. But if you don't need that hassle, then you
> >> > shouldn't take it!
> >> >
> >> > How would a design that works across both CXF and Axis2 work? Its an
> >> > intriguing idea.
> >> >
> >> > Paul
> >> >
> >> >
> >> >
> >> > On Thu, Jun 12, 2008 at 5:02 PM, David Illsley <
> davidillsley@gmail.com>
> >> > wrote:
> >> >> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com>
> >> wrote:
> >> >>> Glen. I didn't think there was any consensus from the previous
> >> >>> discussion (does the word dissensus exist?) :)
> >> >>>
> >> >>> I am actually pretty happy to do either, I think each approach has
> +s
> >> >>> and -s.
> >> >>>
> >> >>> On the side of starting from the Mercury codebase, Amila has got it
> >> to
> >> >>> a point where it satisfies the 1.0 spec, including Replay.
> >> >>> On the other hand, Mercury doesn't yet implement 1.1 or
> >> >>> MakeConnection, and also it doesn't support transactions yet, so
> >> there
> >> >>> are some fairly large aspects still to be coded. And starting afresh
> >> >>> might well get more involvement from the wider community which I
> >> think
> >> >>> has been the main pushback on this proposal so far.
> >> >>
> >> >> Clearly new code developed here will have far fewer legal issues
> (e.g.
> >> >> the submitted Mercury has a hard LGPL dependency which would need
> >> >> ironed out), and would hopefully have a cleaner state machine model -
> >> >> the Mercury one seems to have compromised for reasons which are
> pretty
> >> >> opaque.
> >> >>
> >> >>> I guess one open question is - who is willing to put in the effort
> to
> >> >>> work on this?! If it's just Amila, then starting afresh won't be
> much
> >> >>> benefit, because he will be happier to keep working from the code he
> >> >>> has already built.
> >> >>
> >> >> I'd certainly be interested in being involved in a new codebase, but
> >> >> the amount of time I'd have to devote to it would be limited. If it's
> >> >> just Amila, then my "Apache Way Sense" tingles to suggest that this
> >> >> isn't really going anywhere in Apache, and probably shouldn't.
> >> >>
> >> >> These 2 questions (legal and community) are some of the reasons why
> >> >> the Incubator exists, and sort of points me back in that direction.
> >> >>
> >> >> David
> >> >>
> >> >> P.S. In writing this, it occurred to me that trying to write a common
> >> >> WS-RM kernel that could be used with CXF and Axis2 might be a good
> >> >> target, and that too, might point to the Incubator to help build a
> >> >> broader community (not a fully formed thought though)
> >> >>
> >> >> P.P.S. I really like "dissensus"
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Paul Fremantle
> >> > Co-Founder and CTO, WSO2
> >> > Apache Synapse PMC Chair
> >> > OASIS WS-RX TC Co-chair
> >> >
> >> > blog: http://pzf.fremantle.org
> >> > paul@wso2.com
> >> >
> >> > "Oxygenating the Web Service Platform", www.wso2.com
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17828246.html
> >> Sent from the Apache Sandesha mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17831276.html
> Sent from the Apache Sandesha mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Mercury Proposal
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1000 :)
- -- dims
Daniel Kulp wrote:
|
|
| Pretty much any stack is going to have those same features readily
| available. If Sandesha defined interfaces it needed, then any
| implementation could provide implementations for those interfaces that calls
| back into that implementations versions. It shouldn't be a big deal.
|
| Basically, if there are thoughts to re-architect things based on the Mercury
| code, it's something that would be good to consider from a technical
| viewpoint, but, more importantly, from a community view point as well.
|
| Remember, at Apache, it's community over code. :-)
|
| Dan
|
|
|
| Chamikara Jayalath wrote:
|> We actually considered this idea in the early phases of Sandesha2. After
|> some discussions we thought of going for a Axis2 based one so that we can
|> use all the features that are readily available with Axis2. These included
|> the context hierarchy, pause/resume functionality, Messages Receivers,
|> AXIOM
|> etc.
|>
|> Chamikara
|>
|>
|> On Fri, Jun 13, 2008 at 1:15 PM, Daniel Kulp <dk...@apache.org> wrote:
|>
|>>
|>> Just FYI: I'm also quite interested in the idea of a "generic" RM engine
|>> that could be plugged in to various stacks/providers. Things like WSS4J
|>> and Neethi have been a big help to CXF (and probably others) specifically
|>> because they were "generic" enough to be used outside of Axis. In the
|>> case of WSS4J, it has actually helped the WSS4J community as developers
|>> working on CXF stuff have started contributing to WSS4J as well. Fred
|>> Dushin is now a committer on WSS4J specifically due to work integrating
|>> it
|>> with CXF. Sandesha could potentially benefit similarly if it can become
|>> generic enough to not be considered "just a RM plugin to Axis 2".
|>> Basically, this could be an opportunity to expand the Sandesha community,
|>> and that's a good thing.
|>>
|>> Dan
|>>
|>>
|>>
|>>
|>> pzfreo wrote:
|>>> David
|>>>
|>>> I want to make it clear that I'm *strongly* hoping that there will be
|>>> greater involvement than just one person.
|>>>
|>>> I also *really* like the idea of building an RM implementation that
|>>> has a core model that is not dependent around a specific stack (Axis2,
|>>> CXF). I have always believed that there is a space for a really stable
|>>> and performant WSRM messaging engine and the Sandesha model - where
|>>> the stack is in control and the messaging engine is "just" a set of
|>>> handlers just doesn't feel to me like it can compete with a pure
|>>> messaging option like ActiveMQ or QPid. So in many ways, starting from
|>>> WSRM and treating the problem as "how to build a messaging engine that
|>>> also happens to be able to fit into Axis2" would be very interesting
|>>> to me.
|>>>
|>>> I am actually not against having an incubator proposal. The only
|>>> challenge with the Incubator is that:
|>>> 1) the incubator is fundamentally designed to bootstrap new
|>>> communities. If there is an existing community already then it doesn't
|>>> necessarily work. I would rather have this discussion on sandesha-dev
|>>> than have to somehow encourage everyone from sandesha-dev to start
|>>> paying attention to a new list.
|>>> 2) The incubator is also about how to get non-Apache members involved.
|>>> So far everyone interested in this is already a committer in Apache.
|>>> So in fact, labs.apache.org is more appropriate.
|>>> 3) The incubator is a hassle. Its a hassle for good reasons and I
|>>> strongly support it. But if you don't need that hassle, then you
|>>> shouldn't take it!
|>>>
|>>> How would a design that works across both CXF and Axis2 work? Its an
|>>> intriguing idea.
|>>>
|>>> Paul
|>>>
|>>>
|>>>
|>>> On Thu, Jun 12, 2008 at 5:02 PM, David Illsley <da...@gmail.com>
|>>> wrote:
|>>>> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com>
|>> wrote:
|>>>>> Glen. I didn't think there was any consensus from the previous
|>>>>> discussion (does the word dissensus exist?) :)
|>>>>>
|>>>>> I am actually pretty happy to do either, I think each approach has +s
|>>>>> and -s.
|>>>>>
|>>>>> On the side of starting from the Mercury codebase, Amila has got it
|>> to
|>>>>> a point where it satisfies the 1.0 spec, including Replay.
|>>>>> On the other hand, Mercury doesn't yet implement 1.1 or
|>>>>> MakeConnection, and also it doesn't support transactions yet, so
|>> there
|>>>>> are some fairly large aspects still to be coded. And starting afresh
|>>>>> might well get more involvement from the wider community which I
|>> think
|>>>>> has been the main pushback on this proposal so far.
|>>>> Clearly new code developed here will have far fewer legal issues (e.g.
|>>>> the submitted Mercury has a hard LGPL dependency which would need
|>>>> ironed out), and would hopefully have a cleaner state machine model -
|>>>> the Mercury one seems to have compromised for reasons which are pretty
|>>>> opaque.
|>>>>
|>>>>> I guess one open question is - who is willing to put in the effort to
|>>>>> work on this?! If it's just Amila, then starting afresh won't be much
|>>>>> benefit, because he will be happier to keep working from the code he
|>>>>> has already built.
|>>>> I'd certainly be interested in being involved in a new codebase, but
|>>>> the amount of time I'd have to devote to it would be limited. If it's
|>>>> just Amila, then my "Apache Way Sense" tingles to suggest that this
|>>>> isn't really going anywhere in Apache, and probably shouldn't.
|>>>>
|>>>> These 2 questions (legal and community) are some of the reasons why
|>>>> the Incubator exists, and sort of points me back in that direction.
|>>>>
|>>>> David
|>>>>
|>>>> P.S. In writing this, it occurred to me that trying to write a common
|>>>> WS-RM kernel that could be used with CXF and Axis2 might be a good
|>>>> target, and that too, might point to the Incubator to help build a
|>>>> broader community (not a fully formed thought though)
|>>>>
|>>>> P.P.S. I really like "dissensus"
|>>>>
|>>>> ---------------------------------------------------------------------
|>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
|>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
|>>>>
|>>>>
|>>>
|>>>
|>>> --
|>>> Paul Fremantle
|>>> Co-Founder and CTO, WSO2
|>>> Apache Synapse PMC Chair
|>>> OASIS WS-RX TC Co-chair
|>>>
|>>> blog: http://pzf.fremantle.org
|>>> paul@wso2.com
|>>>
|>>> "Oxygenating the Web Service Platform", www.wso2.com
|>>>
|>>> ---------------------------------------------------------------------
|>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
|>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
|>>>
|>>>
|>>>
|>> --
|>> View this message in context:
|>> http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17828246.html
|>> Sent from the Apache Sandesha mailing list archive at Nabble.com.
|>>
|>>
|>> ---------------------------------------------------------------------
|>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
|>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
|>>
|>>
|>
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIUtb1gNg6eWEDv1kRAmoUAJ9QWbxzTILbMGDq+fNUPb/WjzWe5gCeNlbr
7p7aadA/Wb8Ux7wGSBeMGrU=
=CdJ1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Daniel Kulp <dk...@apache.org>.
Pretty much any stack is going to have those same features readily
available. If Sandesha defined interfaces it needed, then any
implementation could provide implementations for those interfaces that calls
back into that implementations versions. It shouldn't be a big deal.
Basically, if there are thoughts to re-architect things based on the Mercury
code, it's something that would be good to consider from a technical
viewpoint, but, more importantly, from a community view point as well.
Remember, at Apache, it's community over code. :-)
Dan
Chamikara Jayalath wrote:
>
> We actually considered this idea in the early phases of Sandesha2. After
> some discussions we thought of going for a Axis2 based one so that we can
> use all the features that are readily available with Axis2. These included
> the context hierarchy, pause/resume functionality, Messages Receivers,
> AXIOM
> etc.
>
> Chamikara
>
>
> On Fri, Jun 13, 2008 at 1:15 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>>
>> Just FYI: I'm also quite interested in the idea of a "generic" RM engine
>> that could be plugged in to various stacks/providers. Things like WSS4J
>> and Neethi have been a big help to CXF (and probably others) specifically
>> because they were "generic" enough to be used outside of Axis. In the
>> case of WSS4J, it has actually helped the WSS4J community as developers
>> working on CXF stuff have started contributing to WSS4J as well. Fred
>> Dushin is now a committer on WSS4J specifically due to work integrating
>> it
>> with CXF. Sandesha could potentially benefit similarly if it can become
>> generic enough to not be considered "just a RM plugin to Axis 2".
>> Basically, this could be an opportunity to expand the Sandesha community,
>> and that's a good thing.
>>
>> Dan
>>
>>
>>
>>
>> pzfreo wrote:
>> >
>> > David
>> >
>> > I want to make it clear that I'm *strongly* hoping that there will be
>> > greater involvement than just one person.
>> >
>> > I also *really* like the idea of building an RM implementation that
>> > has a core model that is not dependent around a specific stack (Axis2,
>> > CXF). I have always believed that there is a space for a really stable
>> > and performant WSRM messaging engine and the Sandesha model - where
>> > the stack is in control and the messaging engine is "just" a set of
>> > handlers just doesn't feel to me like it can compete with a pure
>> > messaging option like ActiveMQ or QPid. So in many ways, starting from
>> > WSRM and treating the problem as "how to build a messaging engine that
>> > also happens to be able to fit into Axis2" would be very interesting
>> > to me.
>> >
>> > I am actually not against having an incubator proposal. The only
>> > challenge with the Incubator is that:
>> > 1) the incubator is fundamentally designed to bootstrap new
>> > communities. If there is an existing community already then it doesn't
>> > necessarily work. I would rather have this discussion on sandesha-dev
>> > than have to somehow encourage everyone from sandesha-dev to start
>> > paying attention to a new list.
>> > 2) The incubator is also about how to get non-Apache members involved.
>> > So far everyone interested in this is already a committer in Apache.
>> > So in fact, labs.apache.org is more appropriate.
>> > 3) The incubator is a hassle. Its a hassle for good reasons and I
>> > strongly support it. But if you don't need that hassle, then you
>> > shouldn't take it!
>> >
>> > How would a design that works across both CXF and Axis2 work? Its an
>> > intriguing idea.
>> >
>> > Paul
>> >
>> >
>> >
>> > On Thu, Jun 12, 2008 at 5:02 PM, David Illsley <da...@gmail.com>
>> > wrote:
>> >> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com>
>> wrote:
>> >>> Glen. I didn't think there was any consensus from the previous
>> >>> discussion (does the word dissensus exist?) :)
>> >>>
>> >>> I am actually pretty happy to do either, I think each approach has +s
>> >>> and -s.
>> >>>
>> >>> On the side of starting from the Mercury codebase, Amila has got it
>> to
>> >>> a point where it satisfies the 1.0 spec, including Replay.
>> >>> On the other hand, Mercury doesn't yet implement 1.1 or
>> >>> MakeConnection, and also it doesn't support transactions yet, so
>> there
>> >>> are some fairly large aspects still to be coded. And starting afresh
>> >>> might well get more involvement from the wider community which I
>> think
>> >>> has been the main pushback on this proposal so far.
>> >>
>> >> Clearly new code developed here will have far fewer legal issues (e.g.
>> >> the submitted Mercury has a hard LGPL dependency which would need
>> >> ironed out), and would hopefully have a cleaner state machine model -
>> >> the Mercury one seems to have compromised for reasons which are pretty
>> >> opaque.
>> >>
>> >>> I guess one open question is - who is willing to put in the effort to
>> >>> work on this?! If it's just Amila, then starting afresh won't be much
>> >>> benefit, because he will be happier to keep working from the code he
>> >>> has already built.
>> >>
>> >> I'd certainly be interested in being involved in a new codebase, but
>> >> the amount of time I'd have to devote to it would be limited. If it's
>> >> just Amila, then my "Apache Way Sense" tingles to suggest that this
>> >> isn't really going anywhere in Apache, and probably shouldn't.
>> >>
>> >> These 2 questions (legal and community) are some of the reasons why
>> >> the Incubator exists, and sort of points me back in that direction.
>> >>
>> >> David
>> >>
>> >> P.S. In writing this, it occurred to me that trying to write a common
>> >> WS-RM kernel that could be used with CXF and Axis2 might be a good
>> >> target, and that too, might point to the Incubator to help build a
>> >> broader community (not a fully formed thought though)
>> >>
>> >> P.P.S. I really like "dissensus"
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Paul Fremantle
>> > Co-Founder and CTO, WSO2
>> > Apache Synapse PMC Chair
>> > OASIS WS-RX TC Co-chair
>> >
>> > blog: http://pzf.fremantle.org
>> > paul@wso2.com
>> >
>> > "Oxygenating the Web Service Platform", www.wso2.com
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17828246.html
>> Sent from the Apache Sandesha mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17831276.html
Sent from the Apache Sandesha mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Chamikara Jayalath <ch...@gmail.com>.
We actually considered this idea in the early phases of Sandesha2. After
some discussions we thought of going for a Axis2 based one so that we can
use all the features that are readily available with Axis2. These included
the context hierarchy, pause/resume functionality, Messages Receivers, AXIOM
etc.
Chamikara
On Fri, Jun 13, 2008 at 1:15 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>
> Just FYI: I'm also quite interested in the idea of a "generic" RM engine
> that could be plugged in to various stacks/providers. Things like WSS4J
> and Neethi have been a big help to CXF (and probably others) specifically
> because they were "generic" enough to be used outside of Axis. In the
> case of WSS4J, it has actually helped the WSS4J community as developers
> working on CXF stuff have started contributing to WSS4J as well. Fred
> Dushin is now a committer on WSS4J specifically due to work integrating it
> with CXF. Sandesha could potentially benefit similarly if it can become
> generic enough to not be considered "just a RM plugin to Axis 2".
> Basically, this could be an opportunity to expand the Sandesha community,
> and that's a good thing.
>
> Dan
>
>
>
>
> pzfreo wrote:
> >
> > David
> >
> > I want to make it clear that I'm *strongly* hoping that there will be
> > greater involvement than just one person.
> >
> > I also *really* like the idea of building an RM implementation that
> > has a core model that is not dependent around a specific stack (Axis2,
> > CXF). I have always believed that there is a space for a really stable
> > and performant WSRM messaging engine and the Sandesha model - where
> > the stack is in control and the messaging engine is "just" a set of
> > handlers just doesn't feel to me like it can compete with a pure
> > messaging option like ActiveMQ or QPid. So in many ways, starting from
> > WSRM and treating the problem as "how to build a messaging engine that
> > also happens to be able to fit into Axis2" would be very interesting
> > to me.
> >
> > I am actually not against having an incubator proposal. The only
> > challenge with the Incubator is that:
> > 1) the incubator is fundamentally designed to bootstrap new
> > communities. If there is an existing community already then it doesn't
> > necessarily work. I would rather have this discussion on sandesha-dev
> > than have to somehow encourage everyone from sandesha-dev to start
> > paying attention to a new list.
> > 2) The incubator is also about how to get non-Apache members involved.
> > So far everyone interested in this is already a committer in Apache.
> > So in fact, labs.apache.org is more appropriate.
> > 3) The incubator is a hassle. Its a hassle for good reasons and I
> > strongly support it. But if you don't need that hassle, then you
> > shouldn't take it!
> >
> > How would a design that works across both CXF and Axis2 work? Its an
> > intriguing idea.
> >
> > Paul
> >
> >
> >
> > On Thu, Jun 12, 2008 at 5:02 PM, David Illsley <da...@gmail.com>
> > wrote:
> >> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com>
> wrote:
> >>> Glen. I didn't think there was any consensus from the previous
> >>> discussion (does the word dissensus exist?) :)
> >>>
> >>> I am actually pretty happy to do either, I think each approach has +s
> >>> and -s.
> >>>
> >>> On the side of starting from the Mercury codebase, Amila has got it to
> >>> a point where it satisfies the 1.0 spec, including Replay.
> >>> On the other hand, Mercury doesn't yet implement 1.1 or
> >>> MakeConnection, and also it doesn't support transactions yet, so there
> >>> are some fairly large aspects still to be coded. And starting afresh
> >>> might well get more involvement from the wider community which I think
> >>> has been the main pushback on this proposal so far.
> >>
> >> Clearly new code developed here will have far fewer legal issues (e.g.
> >> the submitted Mercury has a hard LGPL dependency which would need
> >> ironed out), and would hopefully have a cleaner state machine model -
> >> the Mercury one seems to have compromised for reasons which are pretty
> >> opaque.
> >>
> >>> I guess one open question is - who is willing to put in the effort to
> >>> work on this?! If it's just Amila, then starting afresh won't be much
> >>> benefit, because he will be happier to keep working from the code he
> >>> has already built.
> >>
> >> I'd certainly be interested in being involved in a new codebase, but
> >> the amount of time I'd have to devote to it would be limited. If it's
> >> just Amila, then my "Apache Way Sense" tingles to suggest that this
> >> isn't really going anywhere in Apache, and probably shouldn't.
> >>
> >> These 2 questions (legal and community) are some of the reasons why
> >> the Incubator exists, and sort of points me back in that direction.
> >>
> >> David
> >>
> >> P.S. In writing this, it occurred to me that trying to write a common
> >> WS-RM kernel that could be used with CXF and Axis2 might be a good
> >> target, and that too, might point to the Incubator to help build a
> >> broader community (not a fully formed thought though)
> >>
> >> P.P.S. I really like "dissensus"
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and CTO, WSO2
> > Apache Synapse PMC Chair
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17828246.html
> Sent from the Apache Sandesha mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: [DISCUSS] Mercury Proposal
Posted by Daniel Kulp <dk...@apache.org>.
Just FYI: I'm also quite interested in the idea of a "generic" RM engine
that could be plugged in to various stacks/providers. Things like WSS4J
and Neethi have been a big help to CXF (and probably others) specifically
because they were "generic" enough to be used outside of Axis. In the
case of WSS4J, it has actually helped the WSS4J community as developers
working on CXF stuff have started contributing to WSS4J as well. Fred
Dushin is now a committer on WSS4J specifically due to work integrating it
with CXF. Sandesha could potentially benefit similarly if it can become
generic enough to not be considered "just a RM plugin to Axis 2".
Basically, this could be an opportunity to expand the Sandesha community,
and that's a good thing.
Dan
pzfreo wrote:
>
> David
>
> I want to make it clear that I'm *strongly* hoping that there will be
> greater involvement than just one person.
>
> I also *really* like the idea of building an RM implementation that
> has a core model that is not dependent around a specific stack (Axis2,
> CXF). I have always believed that there is a space for a really stable
> and performant WSRM messaging engine and the Sandesha model - where
> the stack is in control and the messaging engine is "just" a set of
> handlers just doesn't feel to me like it can compete with a pure
> messaging option like ActiveMQ or QPid. So in many ways, starting from
> WSRM and treating the problem as "how to build a messaging engine that
> also happens to be able to fit into Axis2" would be very interesting
> to me.
>
> I am actually not against having an incubator proposal. The only
> challenge with the Incubator is that:
> 1) the incubator is fundamentally designed to bootstrap new
> communities. If there is an existing community already then it doesn't
> necessarily work. I would rather have this discussion on sandesha-dev
> than have to somehow encourage everyone from sandesha-dev to start
> paying attention to a new list.
> 2) The incubator is also about how to get non-Apache members involved.
> So far everyone interested in this is already a committer in Apache.
> So in fact, labs.apache.org is more appropriate.
> 3) The incubator is a hassle. Its a hassle for good reasons and I
> strongly support it. But if you don't need that hassle, then you
> shouldn't take it!
>
> How would a design that works across both CXF and Axis2 work? Its an
> intriguing idea.
>
> Paul
>
>
>
> On Thu, Jun 12, 2008 at 5:02 PM, David Illsley <da...@gmail.com>
> wrote:
>> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com> wrote:
>>> Glen. I didn't think there was any consensus from the previous
>>> discussion (does the word dissensus exist?) :)
>>>
>>> I am actually pretty happy to do either, I think each approach has +s
>>> and -s.
>>>
>>> On the side of starting from the Mercury codebase, Amila has got it to
>>> a point where it satisfies the 1.0 spec, including Replay.
>>> On the other hand, Mercury doesn't yet implement 1.1 or
>>> MakeConnection, and also it doesn't support transactions yet, so there
>>> are some fairly large aspects still to be coded. And starting afresh
>>> might well get more involvement from the wider community which I think
>>> has been the main pushback on this proposal so far.
>>
>> Clearly new code developed here will have far fewer legal issues (e.g.
>> the submitted Mercury has a hard LGPL dependency which would need
>> ironed out), and would hopefully have a cleaner state machine model -
>> the Mercury one seems to have compromised for reasons which are pretty
>> opaque.
>>
>>> I guess one open question is - who is willing to put in the effort to
>>> work on this?! If it's just Amila, then starting afresh won't be much
>>> benefit, because he will be happier to keep working from the code he
>>> has already built.
>>
>> I'd certainly be interested in being involved in a new codebase, but
>> the amount of time I'd have to devote to it would be limited. If it's
>> just Amila, then my "Apache Way Sense" tingles to suggest that this
>> isn't really going anywhere in Apache, and probably shouldn't.
>>
>> These 2 questions (legal and community) are some of the reasons why
>> the Incubator exists, and sort of points me back in that direction.
>>
>> David
>>
>> P.S. In writing this, it occurred to me that trying to write a common
>> WS-RM kernel that could be used with CXF and Axis2 might be a good
>> target, and that too, might point to the Incubator to help build a
>> broader community (not a fully formed thought though)
>>
>> P.P.S. I really like "dissensus"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17828246.html
Sent from the Apache Sandesha mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Paul Fremantle <pz...@gmail.com>.
David
I want to make it clear that I'm *strongly* hoping that there will be
greater involvement than just one person.
I also *really* like the idea of building an RM implementation that
has a core model that is not dependent around a specific stack (Axis2,
CXF). I have always believed that there is a space for a really stable
and performant WSRM messaging engine and the Sandesha model - where
the stack is in control and the messaging engine is "just" a set of
handlers just doesn't feel to me like it can compete with a pure
messaging option like ActiveMQ or QPid. So in many ways, starting from
WSRM and treating the problem as "how to build a messaging engine that
also happens to be able to fit into Axis2" would be very interesting
to me.
I am actually not against having an incubator proposal. The only
challenge with the Incubator is that:
1) the incubator is fundamentally designed to bootstrap new
communities. If there is an existing community already then it doesn't
necessarily work. I would rather have this discussion on sandesha-dev
than have to somehow encourage everyone from sandesha-dev to start
paying attention to a new list.
2) The incubator is also about how to get non-Apache members involved.
So far everyone interested in this is already a committer in Apache.
So in fact, labs.apache.org is more appropriate.
3) The incubator is a hassle. Its a hassle for good reasons and I
strongly support it. But if you don't need that hassle, then you
shouldn't take it!
How would a design that works across both CXF and Axis2 work? Its an
intriguing idea.
Paul
On Thu, Jun 12, 2008 at 5:02 PM, David Illsley <da...@gmail.com> wrote:
> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com> wrote:
>> Glen. I didn't think there was any consensus from the previous
>> discussion (does the word dissensus exist?) :)
>>
>> I am actually pretty happy to do either, I think each approach has +s and -s.
>>
>> On the side of starting from the Mercury codebase, Amila has got it to
>> a point where it satisfies the 1.0 spec, including Replay.
>> On the other hand, Mercury doesn't yet implement 1.1 or
>> MakeConnection, and also it doesn't support transactions yet, so there
>> are some fairly large aspects still to be coded. And starting afresh
>> might well get more involvement from the wider community which I think
>> has been the main pushback on this proposal so far.
>
> Clearly new code developed here will have far fewer legal issues (e.g.
> the submitted Mercury has a hard LGPL dependency which would need
> ironed out), and would hopefully have a cleaner state machine model -
> the Mercury one seems to have compromised for reasons which are pretty
> opaque.
>
>> I guess one open question is - who is willing to put in the effort to
>> work on this?! If it's just Amila, then starting afresh won't be much
>> benefit, because he will be happier to keep working from the code he
>> has already built.
>
> I'd certainly be interested in being involved in a new codebase, but
> the amount of time I'd have to devote to it would be limited. If it's
> just Amila, then my "Apache Way Sense" tingles to suggest that this
> isn't really going anywhere in Apache, and probably shouldn't.
>
> These 2 questions (legal and community) are some of the reasons why
> the Incubator exists, and sort of points me back in that direction.
>
> David
>
> P.S. In writing this, it occurred to me that trying to write a common
> WS-RM kernel that could be used with CXF and Axis2 might be a good
> target, and that too, might point to the Incubator to help build a
> broader community (not a fully formed thought though)
>
> P.P.S. I really like "dissensus"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Chamikara Jayalath <ch...@gmail.com>.
On Fri, Jun 13, 2008 at 10:10 AM, Jaliya Ekanayake <jn...@gmail.com>
wrote:
> Hi Amila,
>
> I have to correct something related to your previous post. This has nothing
> to do with the Mercury effort.
>
> You mentioned,
> AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then
> people has joined and contributed to it at various times.
>
> It was not like this. When we design Axis2, we all (most of the axis devs)
> discussed the architectures for various modules such as Sandesha. Everybody
> was in agreement with the high-level details of the implementation as well.
> Chamikara and others (Sanka, me ....... (I am sorry if I miss anybody ))
> contributed to the initial code. Then Chamikara pushes it alone and later
> lot of devs joined the effort.
>
>
+1
You missed Saminda :-) He also did initial contributions.
> So, when there is a need people will jump in and I believe that it will the
> same for Mercury as well. As the starting point, I would like to know the
> architecture that you propose for Mercury. (This is not the simulator
> based architecture but how mercury is implemented as an Axis2 module, the
> handlers to be deployed, message receivers to be used etc...)
>
+1. I'll also try to spend some cycles in the future.
Chamikara
>
> Thanks,
> Jaliya
>
>
> ----- Original Message -----
>
> *From:* Amila Suriarachchi <am...@gmail.com>
> *To:* David Illsley <da...@gmail.com>
> *Cc:* sandesha-dev@ws.apache.org
> *Sent:* Friday, June 13, 2008 4:04 AM
> *Subject:* Re: [DISCUSS] Mercury Proposal
>
>
>
> On Thu, Jun 12, 2008 at 9:32 PM, David Illsley <da...@gmail.com>
> wrote:
>
>> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com> wrote:
>> > Glen. I didn't think there was any consensus from the previous
>> > discussion (does the word dissensus exist?) :)
>> >
>> > I am actually pretty happy to do either, I think each approach has +s
>> and -s.
>> >
>> > On the side of starting from the Mercury codebase, Amila has got it to
>> > a point where it satisfies the 1.0 spec, including Replay.
>> > On the other hand, Mercury doesn't yet implement 1.1 or
>> > MakeConnection, and also it doesn't support transactions yet, so there
>> > are some fairly large aspects still to be coded. And starting afresh
>> > might well get more involvement from the wider community which I think
>> > has been the main pushback on this proposal so far.
>>
>> Clearly new code developed here will have far fewer legal issues (e.g.
>> the submitted Mercury has a hard LGPL dependency which would need
>> ironed out),
>
>
> definitely we have to remove the persistence module and re write it using
> direct JDBC. May be the first step to do if it going to apache. If we think
> that Mercury without that part, Then this problem is already solved.
>
> and would hopefully have a cleaner state machine model -
>> the Mercury one seems to have compromised for reasons which are pretty
>> opaque.
>>
>> > I guess one open question is - who is willing to put in the effort to
>> > work on this?! If it's just Amila, then starting afresh won't be much
>> > benefit, because he will be happier to keep working from the code he
>> > has already built.
>>
>> I'd certainly be interested in being involved in a new codebase, but
>> the amount of time I'd have to devote to it would be limited. If it's
>> just Amila, then my "Apache Way Sense" tingles to suggest that this
>> isn't really going anywhere in Apache, and probably shouldn't.
>
>
> AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then
> people has joined and contributed to it at various times. Same thing may
> happen with the Mercury with the time. As Chamikara did with Sandesha2 I can
> initiate it with a new design. But this does not mean it will be a one man
> show for ever.
>
> thanks,
> Amila.
>
>>
>>
>> These 2 questions (legal and community) are some of the reasons why
>> the Incubator exists, and sort of points me back in that direction.
>>
>> David
>>
>> P.S. In writing this, it occurred to me that trying to write a common
>> WS-RM kernel that could be used with CXF and Axis2 might be a good
>> target, and that too, might point to the Incubator to help build a
>> broader community (not a fully formed thought though)
>>
>> P.P.S. I really like "dissensus"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
Re: [DISCUSS] Mercury Proposal
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Jun 13, 2008 at 7:40 PM, Jaliya Ekanayake <jn...@gmail.com>
wrote:
> Hi Amila,
>
> I have to correct something related to your previous post. This has nothing
> to do with the Mercury effort.
>
> You mentioned,
> AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then
> people has joined and contributed to it at various times.
>
> It was not like this. When we design Axis2, we all (most of the axis devs)
> discussed the architectures for various modules such as Sandesha. Everybody
> was in agreement with the high-level details of the implementation as well.
> Chamikara and others (Sanka, me ....... (I am sorry if I miss anybody ))
> contributed to the initial code. Then Chamikara pushes it alone and later
> lot of devs joined the effort.
>
Thank you very much for the correction. I really apologize you. (Of course I
have written it under AFAIK).
> So, when there is a need people will jump in and I believe that it will the
> same for Mercury as well. As the starting point, I would like to know the
> architecture that you propose for Mercury. (This is not the simulator
> based architecture but how mercury is implemented as an Axis2 module, the
> handlers to be deployed, message receivers to be used etc...)
>
This is what I mean.
We can divide the Mercury into two parts.
1. The state machine model.
This is the part which ensure handling unreliability, proper message
flow, in order/exactly one delivery, sequence creation termination etc ...
roughly talking most of the aspects the WS-RM spec talks about. So I think
it is very easy to understand how mercury address those things in the
simulator model.
2. Implementation of this model as an Axis2 Module.
This is the part where its real implementation happens. To understand
this one should have a proper knowledge about the Axis2 Architecture and its
thread model, object model (Axiom) etc...
if you go to the module.xml file then you can understand what are the
handlers Mercury users and where each handler fit in each message flow.
(input, output and fault flows)
if you go to these handlers you can see it try to figure out the various
event receives using the action. then updates the state machine model
accordingly. First try to figure out the Duplex mode ( not anonymous). Which
is easier.
Any Axis2 module gets the messages from a handler. First Mercury try to
understand the MessageReceived using the Action. And the do the necessary
state machine updates.
There are separate set of threads called worker threads which do the
appropriate actions on the State machines according to their states.
thanks,
Amila.
>
> Thanks,
> Jaliya
>
>
> ----- Original Message -----
>
> *From:* Amila Suriarachchi <am...@gmail.com>
> *To:* David Illsley <da...@gmail.com>
> *Cc:* sandesha-dev@ws.apache.org
> *Sent:* Friday, June 13, 2008 4:04 AM
> *Subject:* Re: [DISCUSS] Mercury Proposal
>
>
>
> On Thu, Jun 12, 2008 at 9:32 PM, David Illsley <da...@gmail.com>
> wrote:
>
>> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com> wrote:
>> > Glen. I didn't think there was any consensus from the previous
>> > discussion (does the word dissensus exist?) :)
>> >
>> > I am actually pretty happy to do either, I think each approach has +s
>> and -s.
>> >
>> > On the side of starting from the Mercury codebase, Amila has got it to
>> > a point where it satisfies the 1.0 spec, including Replay.
>> > On the other hand, Mercury doesn't yet implement 1.1 or
>> > MakeConnection, and also it doesn't support transactions yet, so there
>> > are some fairly large aspects still to be coded. And starting afresh
>> > might well get more involvement from the wider community which I think
>> > has been the main pushback on this proposal so far.
>>
>> Clearly new code developed here will have far fewer legal issues (e.g.
>> the submitted Mercury has a hard LGPL dependency which would need
>> ironed out),
>
>
> definitely we have to remove the persistence module and re write it using
> direct JDBC. May be the first step to do if it going to apache. If we think
> that Mercury without that part, Then this problem is already solved.
>
> and would hopefully have a cleaner state machine model -
>> the Mercury one seems to have compromised for reasons which are pretty
>> opaque.
>>
>> > I guess one open question is - who is willing to put in the effort to
>> > work on this?! If it's just Amila, then starting afresh won't be much
>> > benefit, because he will be happier to keep working from the code he
>> > has already built.
>>
>> I'd certainly be interested in being involved in a new codebase, but
>> the amount of time I'd have to devote to it would be limited. If it's
>> just Amila, then my "Apache Way Sense" tingles to suggest that this
>> isn't really going anywhere in Apache, and probably shouldn't.
>
>
> AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then
> people has joined and contributed to it at various times. Same thing may
> happen with the Mercury with the time. As Chamikara did with Sandesha2 I can
> initiate it with a new design. But this does not mean it will be a one man
> show for ever.
>
> thanks,
> Amila.
>
>>
>>
>> These 2 questions (legal and community) are some of the reasons why
>> the Incubator exists, and sort of points me back in that direction.
>>
>> David
>>
>> P.S. In writing this, it occurred to me that trying to write a common
>> WS-RM kernel that could be used with CXF and Axis2 might be a good
>> target, and that too, might point to the Incubator to help build a
>> broader community (not a fully formed thought though)
>>
>> P.P.S. I really like "dissensus"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [DISCUSS] Mercury Proposal
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Amila,
I have to correct something related to your previous post. This has nothing to do with the Mercury effort.
You mentioned,
AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then people has joined and contributed to it at various times.
It was not like this. When we design Axis2, we all (most of the axis devs) discussed the architectures for various modules such as Sandesha. Everybody was in agreement with the high-level details of the implementation as well. Chamikara and others (Sanka, me ....... (I am sorry if I miss anybody )) contributed to the initial code. Then Chamikara pushes it alone and later lot of devs joined the effort.
So, when there is a need people will jump in and I believe that it will the same for Mercury as well. As the starting point, I would like to know the architecture that you propose for Mercury. (This is not the simulator based architecture but how mercury is implemented as an Axis2 module, the handlers to be deployed, message receivers to be used etc...)
Thanks,
Jaliya
----- Original Message -----
From: Amila Suriarachchi
To: David Illsley
Cc: sandesha-dev@ws.apache.org
Sent: Friday, June 13, 2008 4:04 AM
Subject: Re: [DISCUSS] Mercury Proposal
On Thu, Jun 12, 2008 at 9:32 PM, David Illsley <da...@gmail.com> wrote:
On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Glen. I didn't think there was any consensus from the previous
> discussion (does the word dissensus exist?) :)
>
> I am actually pretty happy to do either, I think each approach has +s and -s.
>
> On the side of starting from the Mercury codebase, Amila has got it to
> a point where it satisfies the 1.0 spec, including Replay.
> On the other hand, Mercury doesn't yet implement 1.1 or
> MakeConnection, and also it doesn't support transactions yet, so there
> are some fairly large aspects still to be coded. And starting afresh
> might well get more involvement from the wider community which I think
> has been the main pushback on this proposal so far.
Clearly new code developed here will have far fewer legal issues (e.g.
the submitted Mercury has a hard LGPL dependency which would need
ironed out),
definitely we have to remove the persistence module and re write it using direct JDBC. May be the first step to do if it going to apache. If we think that Mercury without that part, Then this problem is already solved.
and would hopefully have a cleaner state machine model -
the Mercury one seems to have compromised for reasons which are pretty
opaque.
> I guess one open question is - who is willing to put in the effort to
> work on this?! If it's just Amila, then starting afresh won't be much
> benefit, because he will be happier to keep working from the code he
> has already built.
I'd certainly be interested in being involved in a new codebase, but
the amount of time I'd have to devote to it would be limited. If it's
just Amila, then my "Apache Way Sense" tingles to suggest that this
isn't really going anywhere in Apache, and probably shouldn't.
AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then people has joined and contributed to it at various times. Same thing may happen with the Mercury with the time. As Chamikara did with Sandesha2 I can initiate it with a new design. But this does not mean it will be a one man show for ever.
thanks,
Amila.
These 2 questions (legal and community) are some of the reasons why
the Incubator exists, and sort of points me back in that direction.
David
P.S. In writing this, it occurred to me that trying to write a common
WS-RM kernel that could be used with CXF and Axis2 might be a good
target, and that too, might point to the Incubator to help build a
broader community (not a fully formed thought though)
P.P.S. I really like "dissensus"
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
--
Amila Suriarachchi,
WSO2 Inc.
Re: [DISCUSS] Mercury Proposal
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Jun 12, 2008 at 9:32 PM, David Illsley <da...@gmail.com>
wrote:
> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com> wrote:
> > Glen. I didn't think there was any consensus from the previous
> > discussion (does the word dissensus exist?) :)
> >
> > I am actually pretty happy to do either, I think each approach has +s and
> -s.
> >
> > On the side of starting from the Mercury codebase, Amila has got it to
> > a point where it satisfies the 1.0 spec, including Replay.
> > On the other hand, Mercury doesn't yet implement 1.1 or
> > MakeConnection, and also it doesn't support transactions yet, so there
> > are some fairly large aspects still to be coded. And starting afresh
> > might well get more involvement from the wider community which I think
> > has been the main pushback on this proposal so far.
>
> Clearly new code developed here will have far fewer legal issues (e.g.
> the submitted Mercury has a hard LGPL dependency which would need
> ironed out),
definitely we have to remove the persistence module and re write it using
direct JDBC. May be the first step to do if it going to apache. If we think
that Mercury without that part, Then this problem is already solved.
and would hopefully have a cleaner state machine model -
> the Mercury one seems to have compromised for reasons which are pretty
> opaque.
>
> > I guess one open question is - who is willing to put in the effort to
> > work on this?! If it's just Amila, then starting afresh won't be much
> > benefit, because he will be happier to keep working from the code he
> > has already built.
>
> I'd certainly be interested in being involved in a new codebase, but
> the amount of time I'd have to devote to it would be limited. If it's
> just Amila, then my "Apache Way Sense" tingles to suggest that this
> isn't really going anywhere in Apache, and probably shouldn't.
AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then
people has joined and contributed to it at various times. Same thing may
happen with the Mercury with the time. As Chamikara did with Sandesha2 I can
initiate it with a new design. But this does not mean it will be a one man
show for ever.
thanks,
Amila.
>
>
> These 2 questions (legal and community) are some of the reasons why
> the Incubator exists, and sort of points me back in that direction.
>
> David
>
> P.S. In writing this, it occurred to me that trying to write a common
> WS-RM kernel that could be used with CXF and Axis2 might be a good
> target, and that too, might point to the Incubator to help build a
> broader community (not a fully formed thought though)
>
> P.P.S. I really like "dissensus"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [DISCUSS] Mercury Proposal
Posted by David Illsley <da...@gmail.com>.
On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Glen. I didn't think there was any consensus from the previous
> discussion (does the word dissensus exist?) :)
>
> I am actually pretty happy to do either, I think each approach has +s and -s.
>
> On the side of starting from the Mercury codebase, Amila has got it to
> a point where it satisfies the 1.0 spec, including Replay.
> On the other hand, Mercury doesn't yet implement 1.1 or
> MakeConnection, and also it doesn't support transactions yet, so there
> are some fairly large aspects still to be coded. And starting afresh
> might well get more involvement from the wider community which I think
> has been the main pushback on this proposal so far.
Clearly new code developed here will have far fewer legal issues (e.g.
the submitted Mercury has a hard LGPL dependency which would need
ironed out), and would hopefully have a cleaner state machine model -
the Mercury one seems to have compromised for reasons which are pretty
opaque.
> I guess one open question is - who is willing to put in the effort to
> work on this?! If it's just Amila, then starting afresh won't be much
> benefit, because he will be happier to keep working from the code he
> has already built.
I'd certainly be interested in being involved in a new codebase, but
the amount of time I'd have to devote to it would be limited. If it's
just Amila, then my "Apache Way Sense" tingles to suggest that this
isn't really going anywhere in Apache, and probably shouldn't.
These 2 questions (legal and community) are some of the reasons why
the Incubator exists, and sort of points me back in that direction.
David
P.S. In writing this, it occurred to me that trying to write a common
WS-RM kernel that could be used with CXF and Axis2 might be a good
target, and that too, might point to the Incubator to help build a
broader community (not a fully formed thought though)
P.P.S. I really like "dissensus"
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Paul Fremantle <pz...@gmail.com>.
Glen. I didn't think there was any consensus from the previous
discussion (does the word dissensus exist?) :)
I am actually pretty happy to do either, I think each approach has +s and -s.
On the side of starting from the Mercury codebase, Amila has got it to
a point where it satisfies the 1.0 spec, including Replay.
On the other hand, Mercury doesn't yet implement 1.1 or
MakeConnection, and also it doesn't support transactions yet, so there
are some fairly large aspects still to be coded. And starting afresh
might well get more involvement from the wider community which I think
has been the main pushback on this proposal so far.
I guess one open question is - who is willing to put in the effort to
work on this?! If it's just Amila, then starting afresh won't be much
benefit, because he will be happier to keep working from the code he
has already built. If there is a wider set of people willing to put in
effort, then starting afresh might have significant benefits.
Paul
On Thu, Jun 12, 2008 at 2:53 AM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Paul:
>
> Paul Fremantle wrote:
>>
>> I have posted a proposal here:
>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>
>> Please edit, improve, or discuss.... I put this in the wiki so that it
>> could be modified.
>
> Hm... I thought where we'd ended up discussion-wise was that we would get
> the Mercury code granted to Apache so that it could be examined / learned
> from / experimented with, but that we would aim to create a "third way" as
> the next step for both projects.
>
> In other words, the actual work that happens to make the new "unified" RM
> implementation (whatever it ends up being called) would start with a clean
> slate and take whatever it can from both Sandesha and Mercury, with the goal
> of making sure that all the active developers are involved and empowered.
> Did I understand that right?
>
> Your proposal makes it sound rather like we're going to just start from the
> existing Mercury code and go from there.
>
> --Glen
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Jun 12, 2008 at 9:55 AM, Jaliya Ekanayake <jn...@gmail.com>
wrote:
> Hi Paul,
>
> The proposal starts with a "state machine model" which Mercury has come up
> with.
> So can you give little bit more details on the state machine model that
> you are suggesting?
Please refer to the Architecture.pdf under the docs folder of the Mercury
distribution. And also please see the simulator which is under the jira.
That shows how the state machine model works on top of the Axis2 simulator.
Feel free to raise any questions.
thanks,
Amila.
>
>
> Thanks,
> Jaliya
>
>
> ----- Original Message ----- From: "Glen Daniels" <gl...@thoughtcraft.com>
> To: "Paul Fremantle" <pz...@gmail.com>
> Cc: <sa...@ws.apache.org>; <ge...@ws.apache.org>
> Sent: Wednesday, June 11, 2008 9:53 PM
> Subject: Re: [DISCUSS] Mercury Proposal
>
>
> Hi Paul:
>>
>> Paul Fremantle wrote:
>>
>>> I have posted a proposal here:
>>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>>
>>> Please edit, improve, or discuss.... I put this in the wiki so that it
>>> could be modified.
>>>
>>
>> Hm... I thought where we'd ended up discussion-wise was that we would get
>> the Mercury code granted to Apache so that it could be examined / learned
>> from / experimented with, but that we would aim to create a "third way" as
>> the next step for both projects.
>>
>> In other words, the actual work that happens to make the new "unified" RM
>> implementation (whatever it ends up being called) would start with a clean
>> slate and take whatever it can from both Sandesha and Mercury, with the goal
>> of making sure that all the active developers are involved and empowered.
>> Did I understand that right?
>>
>> Your proposal makes it sound rather like we're going to just start from
>> the existing Mercury code and go from there.
>>
>> --Glen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
>> For additional commands, e-mail: general-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [DISCUSS] Mercury Proposal
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul and Amila,
Sure, let me go through the docs and come back to you.
Thanks,
Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: "Jaliya Ekanayake" <ja...@apache.org>
Cc: <ge...@ws.apache.org>; <sa...@ws.apache.org>
Sent: Thursday, June 12, 2008 8:18 AM
Subject: Re: [DISCUSS] Mercury Proposal
> And a link:
> http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.html
>
> Paul
>
> On Thu, Jun 12, 2008 at 1:17 PM, Paul Fremantle <pz...@gmail.com> wrote:
>> Jaliya
>>
>> Actually, although Mercury has got a state machine model, I would
>> personally prefer if we started directly from the State Machine
>> published in the Appendix of the WSRM1.1 specification, and worked
>> from here. I think we need two different implementations of a SM - one
>> for 1.0 and one for 1.1, so we would have to create the equivalent
>> documentation for 1.0. Amila has a pretty good starting point for the
>> 1.0 SM, and there needs to be some further discussion about exactly
>> how that should look.
>>
>> Paul
>>
>>
>>
>> On Thu, Jun 12, 2008 at 5:25 AM, Jaliya Ekanayake <jn...@gmail.com>
>> wrote:
>>> Hi Paul,
>>>
>>> The proposal starts with a "state machine model" which Mercury has come
>>> up
>>> with.
>>> So can you give little bit more details on the state machine model that
>>> you
>>> are suggesting?
>>>
>>> Thanks,
>>> Jaliya
>>>
>>>
>>> ----- Original Message ----- From: "Glen Daniels"
>>> <gl...@thoughtcraft.com>
>>> To: "Paul Fremantle" <pz...@gmail.com>
>>> Cc: <sa...@ws.apache.org>; <ge...@ws.apache.org>
>>> Sent: Wednesday, June 11, 2008 9:53 PM
>>> Subject: Re: [DISCUSS] Mercury Proposal
>>>
>>>
>>>> Hi Paul:
>>>>
>>>> Paul Fremantle wrote:
>>>>>
>>>>> I have posted a proposal here:
>>>>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>>>>
>>>>> Please edit, improve, or discuss.... I put this in the wiki so that it
>>>>> could be modified.
>>>>
>>>> Hm... I thought where we'd ended up discussion-wise was that we would
>>>> get
>>>> the Mercury code granted to Apache so that it could be examined /
>>>> learned
>>>> from / experimented with, but that we would aim to create a "third way"
>>>> as
>>>> the next step for both projects.
>>>>
>>>> In other words, the actual work that happens to make the new "unified"
>>>> RM
>>>> implementation (whatever it ends up being called) would start with a
>>>> clean
>>>> slate and take whatever it can from both Sandesha and Mercury, with the
>>>> goal
>>>> of making sure that all the active developers are involved and
>>>> empowered.
>>>> Did I understand that right?
>>>>
>>>> Your proposal makes it sound rather like we're going to just start from
>>>> the existing Mercury code and go from there.
>>>>
>>>> --Glen
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: general-help@ws.apache.org
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
> For additional commands, e-mail: general-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Paul Fremantle <pz...@gmail.com>.
And a link:
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.html
Paul
On Thu, Jun 12, 2008 at 1:17 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Jaliya
>
> Actually, although Mercury has got a state machine model, I would
> personally prefer if we started directly from the State Machine
> published in the Appendix of the WSRM1.1 specification, and worked
> from here. I think we need two different implementations of a SM - one
> for 1.0 and one for 1.1, so we would have to create the equivalent
> documentation for 1.0. Amila has a pretty good starting point for the
> 1.0 SM, and there needs to be some further discussion about exactly
> how that should look.
>
> Paul
>
>
>
> On Thu, Jun 12, 2008 at 5:25 AM, Jaliya Ekanayake <jn...@gmail.com> wrote:
>> Hi Paul,
>>
>> The proposal starts with a "state machine model" which Mercury has come up
>> with.
>> So can you give little bit more details on the state machine model that you
>> are suggesting?
>>
>> Thanks,
>> Jaliya
>>
>>
>> ----- Original Message ----- From: "Glen Daniels" <gl...@thoughtcraft.com>
>> To: "Paul Fremantle" <pz...@gmail.com>
>> Cc: <sa...@ws.apache.org>; <ge...@ws.apache.org>
>> Sent: Wednesday, June 11, 2008 9:53 PM
>> Subject: Re: [DISCUSS] Mercury Proposal
>>
>>
>>> Hi Paul:
>>>
>>> Paul Fremantle wrote:
>>>>
>>>> I have posted a proposal here:
>>>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>>>
>>>> Please edit, improve, or discuss.... I put this in the wiki so that it
>>>> could be modified.
>>>
>>> Hm... I thought where we'd ended up discussion-wise was that we would get
>>> the Mercury code granted to Apache so that it could be examined / learned
>>> from / experimented with, but that we would aim to create a "third way" as
>>> the next step for both projects.
>>>
>>> In other words, the actual work that happens to make the new "unified" RM
>>> implementation (whatever it ends up being called) would start with a clean
>>> slate and take whatever it can from both Sandesha and Mercury, with the goal
>>> of making sure that all the active developers are involved and empowered.
>>> Did I understand that right?
>>>
>>> Your proposal makes it sound rather like we're going to just start from
>>> the existing Mercury code and go from there.
>>>
>>> --Glen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: general-help@ws.apache.org
>>>
>>
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Paul Fremantle <pz...@gmail.com>.
And a link:
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.html
Paul
On Thu, Jun 12, 2008 at 1:17 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Jaliya
>
> Actually, although Mercury has got a state machine model, I would
> personally prefer if we started directly from the State Machine
> published in the Appendix of the WSRM1.1 specification, and worked
> from here. I think we need two different implementations of a SM - one
> for 1.0 and one for 1.1, so we would have to create the equivalent
> documentation for 1.0. Amila has a pretty good starting point for the
> 1.0 SM, and there needs to be some further discussion about exactly
> how that should look.
>
> Paul
>
>
>
> On Thu, Jun 12, 2008 at 5:25 AM, Jaliya Ekanayake <jn...@gmail.com> wrote:
>> Hi Paul,
>>
>> The proposal starts with a "state machine model" which Mercury has come up
>> with.
>> So can you give little bit more details on the state machine model that you
>> are suggesting?
>>
>> Thanks,
>> Jaliya
>>
>>
>> ----- Original Message ----- From: "Glen Daniels" <gl...@thoughtcraft.com>
>> To: "Paul Fremantle" <pz...@gmail.com>
>> Cc: <sa...@ws.apache.org>; <ge...@ws.apache.org>
>> Sent: Wednesday, June 11, 2008 9:53 PM
>> Subject: Re: [DISCUSS] Mercury Proposal
>>
>>
>>> Hi Paul:
>>>
>>> Paul Fremantle wrote:
>>>>
>>>> I have posted a proposal here:
>>>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>>>
>>>> Please edit, improve, or discuss.... I put this in the wiki so that it
>>>> could be modified.
>>>
>>> Hm... I thought where we'd ended up discussion-wise was that we would get
>>> the Mercury code granted to Apache so that it could be examined / learned
>>> from / experimented with, but that we would aim to create a "third way" as
>>> the next step for both projects.
>>>
>>> In other words, the actual work that happens to make the new "unified" RM
>>> implementation (whatever it ends up being called) would start with a clean
>>> slate and take whatever it can from both Sandesha and Mercury, with the goal
>>> of making sure that all the active developers are involved and empowered.
>>> Did I understand that right?
>>>
>>> Your proposal makes it sound rather like we're going to just start from
>>> the existing Mercury code and go from there.
>>>
>>> --Glen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: general-help@ws.apache.org
>>>
>>
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Paul Fremantle <pz...@gmail.com>.
Jaliya
Actually, although Mercury has got a state machine model, I would
personally prefer if we started directly from the State Machine
published in the Appendix of the WSRM1.1 specification, and worked
from here. I think we need two different implementations of a SM - one
for 1.0 and one for 1.1, so we would have to create the equivalent
documentation for 1.0. Amila has a pretty good starting point for the
1.0 SM, and there needs to be some further discussion about exactly
how that should look.
Paul
On Thu, Jun 12, 2008 at 5:25 AM, Jaliya Ekanayake <jn...@gmail.com> wrote:
> Hi Paul,
>
> The proposal starts with a "state machine model" which Mercury has come up
> with.
> So can you give little bit more details on the state machine model that you
> are suggesting?
>
> Thanks,
> Jaliya
>
>
> ----- Original Message ----- From: "Glen Daniels" <gl...@thoughtcraft.com>
> To: "Paul Fremantle" <pz...@gmail.com>
> Cc: <sa...@ws.apache.org>; <ge...@ws.apache.org>
> Sent: Wednesday, June 11, 2008 9:53 PM
> Subject: Re: [DISCUSS] Mercury Proposal
>
>
>> Hi Paul:
>>
>> Paul Fremantle wrote:
>>>
>>> I have posted a proposal here:
>>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>>
>>> Please edit, improve, or discuss.... I put this in the wiki so that it
>>> could be modified.
>>
>> Hm... I thought where we'd ended up discussion-wise was that we would get
>> the Mercury code granted to Apache so that it could be examined / learned
>> from / experimented with, but that we would aim to create a "third way" as
>> the next step for both projects.
>>
>> In other words, the actual work that happens to make the new "unified" RM
>> implementation (whatever it ends up being called) would start with a clean
>> slate and take whatever it can from both Sandesha and Mercury, with the goal
>> of making sure that all the active developers are involved and empowered.
>> Did I understand that right?
>>
>> Your proposal makes it sound rather like we're going to just start from
>> the existing Mercury code and go from there.
>>
>> --Glen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
>> For additional commands, e-mail: general-help@ws.apache.org
>>
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Paul Fremantle <pz...@gmail.com>.
Jaliya
Actually, although Mercury has got a state machine model, I would
personally prefer if we started directly from the State Machine
published in the Appendix of the WSRM1.1 specification, and worked
from here. I think we need two different implementations of a SM - one
for 1.0 and one for 1.1, so we would have to create the equivalent
documentation for 1.0. Amila has a pretty good starting point for the
1.0 SM, and there needs to be some further discussion about exactly
how that should look.
Paul
On Thu, Jun 12, 2008 at 5:25 AM, Jaliya Ekanayake <jn...@gmail.com> wrote:
> Hi Paul,
>
> The proposal starts with a "state machine model" which Mercury has come up
> with.
> So can you give little bit more details on the state machine model that you
> are suggesting?
>
> Thanks,
> Jaliya
>
>
> ----- Original Message ----- From: "Glen Daniels" <gl...@thoughtcraft.com>
> To: "Paul Fremantle" <pz...@gmail.com>
> Cc: <sa...@ws.apache.org>; <ge...@ws.apache.org>
> Sent: Wednesday, June 11, 2008 9:53 PM
> Subject: Re: [DISCUSS] Mercury Proposal
>
>
>> Hi Paul:
>>
>> Paul Fremantle wrote:
>>>
>>> I have posted a proposal here:
>>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>>
>>> Please edit, improve, or discuss.... I put this in the wiki so that it
>>> could be modified.
>>
>> Hm... I thought where we'd ended up discussion-wise was that we would get
>> the Mercury code granted to Apache so that it could be examined / learned
>> from / experimented with, but that we would aim to create a "third way" as
>> the next step for both projects.
>>
>> In other words, the actual work that happens to make the new "unified" RM
>> implementation (whatever it ends up being called) would start with a clean
>> slate and take whatever it can from both Sandesha and Mercury, with the goal
>> of making sure that all the active developers are involved and empowered.
>> Did I understand that right?
>>
>> Your proposal makes it sound rather like we're going to just start from
>> the existing Mercury code and go from there.
>>
>> --Glen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
>> For additional commands, e-mail: general-help@ws.apache.org
>>
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
The proposal starts with a "state machine model" which Mercury has come up
with.
So can you give little bit more details on the state machine model that you
are suggesting?
Thanks,
Jaliya
----- Original Message -----
From: "Glen Daniels" <gl...@thoughtcraft.com>
To: "Paul Fremantle" <pz...@gmail.com>
Cc: <sa...@ws.apache.org>; <ge...@ws.apache.org>
Sent: Wednesday, June 11, 2008 9:53 PM
Subject: Re: [DISCUSS] Mercury Proposal
> Hi Paul:
>
> Paul Fremantle wrote:
>> I have posted a proposal here:
>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>
>> Please edit, improve, or discuss.... I put this in the wiki so that it
>> could be modified.
>
> Hm... I thought where we'd ended up discussion-wise was that we would get
> the Mercury code granted to Apache so that it could be examined / learned
> from / experimented with, but that we would aim to create a "third way" as
> the next step for both projects.
>
> In other words, the actual work that happens to make the new "unified" RM
> implementation (whatever it ends up being called) would start with a clean
> slate and take whatever it can from both Sandesha and Mercury, with the
> goal of making sure that all the active developers are involved and
> empowered. Did I understand that right?
>
> Your proposal makes it sound rather like we're going to just start from
> the existing Mercury code and go from there.
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
> For additional commands, e-mail: general-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
The proposal starts with a "state machine model" which Mercury has come up
with.
So can you give little bit more details on the state machine model that you
are suggesting?
Thanks,
Jaliya
----- Original Message -----
From: "Glen Daniels" <gl...@thoughtcraft.com>
To: "Paul Fremantle" <pz...@gmail.com>
Cc: <sa...@ws.apache.org>; <ge...@ws.apache.org>
Sent: Wednesday, June 11, 2008 9:53 PM
Subject: Re: [DISCUSS] Mercury Proposal
> Hi Paul:
>
> Paul Fremantle wrote:
>> I have posted a proposal here:
>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>
>> Please edit, improve, or discuss.... I put this in the wiki so that it
>> could be modified.
>
> Hm... I thought where we'd ended up discussion-wise was that we would get
> the Mercury code granted to Apache so that it could be examined / learned
> from / experimented with, but that we would aim to create a "third way" as
> the next step for both projects.
>
> In other words, the actual work that happens to make the new "unified" RM
> implementation (whatever it ends up being called) would start with a clean
> slate and take whatever it can from both Sandesha and Mercury, with the
> goal of making sure that all the active developers are involved and
> empowered. Did I understand that right?
>
> Your proposal makes it sound rather like we're going to just start from
> the existing Mercury code and go from there.
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
> For additional commands, e-mail: general-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Paul Fremantle <pz...@gmail.com>.
Glen. I didn't think there was any consensus from the previous
discussion (does the word dissensus exist?) :)
I am actually pretty happy to do either, I think each approach has +s and -s.
On the side of starting from the Mercury codebase, Amila has got it to
a point where it satisfies the 1.0 spec, including Replay.
On the other hand, Mercury doesn't yet implement 1.1 or
MakeConnection, and also it doesn't support transactions yet, so there
are some fairly large aspects still to be coded. And starting afresh
might well get more involvement from the wider community which I think
has been the main pushback on this proposal so far.
I guess one open question is - who is willing to put in the effort to
work on this?! If it's just Amila, then starting afresh won't be much
benefit, because he will be happier to keep working from the code he
has already built. If there is a wider set of people willing to put in
effort, then starting afresh might have significant benefits.
Paul
On Thu, Jun 12, 2008 at 2:53 AM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Paul:
>
> Paul Fremantle wrote:
>>
>> I have posted a proposal here:
>> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>>
>> Please edit, improve, or discuss.... I put this in the wiki so that it
>> could be modified.
>
> Hm... I thought where we'd ended up discussion-wise was that we would get
> the Mercury code granted to Apache so that it could be examined / learned
> from / experimented with, but that we would aim to create a "third way" as
> the next step for both projects.
>
> In other words, the actual work that happens to make the new "unified" RM
> implementation (whatever it ends up being called) would start with a clean
> slate and take whatever it can from both Sandesha and Mercury, with the goal
> of making sure that all the active developers are involved and empowered.
> Did I understand that right?
>
> Your proposal makes it sound rather like we're going to just start from the
> existing Mercury code and go from there.
>
> --Glen
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Paul:
Paul Fremantle wrote:
> I have posted a proposal here:
> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>
> Please edit, improve, or discuss.... I put this in the wiki so that it
> could be modified.
Hm... I thought where we'd ended up discussion-wise was that we would
get the Mercury code granted to Apache so that it could be examined /
learned from / experimented with, but that we would aim to create a
"third way" as the next step for both projects.
In other words, the actual work that happens to make the new "unified"
RM implementation (whatever it ends up being called) would start with a
clean slate and take whatever it can from both Sandesha and Mercury,
with the goal of making sure that all the active developers are involved
and empowered. Did I understand that right?
Your proposal makes it sound rather like we're going to just start from
the existing Mercury code and go from there.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [DISCUSS] Mercury Proposal
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Paul:
Paul Fremantle wrote:
> I have posted a proposal here:
> http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal
>
> Please edit, improve, or discuss.... I put this in the wiki so that it
> could be modified.
Hm... I thought where we'd ended up discussion-wise was that we would
get the Mercury code granted to Apache so that it could be examined /
learned from / experimented with, but that we would aim to create a
"third way" as the next step for both projects.
In other words, the actual work that happens to make the new "unified"
RM implementation (whatever it ends up being called) would start with a
clean slate and take whatever it can from both Sandesha and Mercury,
with the goal of making sure that all the active developers are involved
and empowered. Did I understand that right?
Your proposal makes it sound rather like we're going to just start from
the existing Mercury code and go from there.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org