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]
