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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > wrote: > >> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > -- > > Paul Fremantle > > Co-Founder and CTO, WSO2 > > Apache Synapse PMC Chair > > OASIS WS-RX TC Co-chair > > > > blog: http://pzf.fremantle.org > > [EMAIL PROTECTED] > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
