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 <[EMAIL PROTECTED]> 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 <[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] > >> > >> > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
