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]
