You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Apache Wiki <wi...@apache.org> on 2008/06/12 03:11:11 UTC

[Ws Wiki] Update of "FrontPage/ws-sandesha/MercuryProposal" by PaulFremantle

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by PaulFremantle:
http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal

New page:
=== This is a proposal for how to deal with the code known as Mercury ===

This is a proposal for how to deal with the alternate Axis2 WSRM implementation that has been donated to Apache [https://issues.apache.org/jira/browse/SANDESHA2-144]

Firstly, it has been suggested that anyone participating in this discussion familiarize themselves with:
[http://incubator.apache.org/learn/rules-for-revolutionaries.html Rules for revolutionaries]

Secondly, this proposal is open for discussion, editing and modification. It is in the wiki to encourage free editing and involvement in the Apache WS and Sandesha communities.

 * There will be a new branch created in SVN for Mercury. It will not replace the Sandesha2 trunk.

 * This is not a proposal to replace Sandesha2. It is a proposal to write a new implementation with a different core design. Of course much can be learnt from Sandesha2 and if possible code re-used.

 * The aim of Mercury will be to create a WSRM implementation that:
  i. Is based on a state machine model
  i. Has a clean separation between the WSRM 1.0 and WSRM 1.1 logic 
  i. Has a clean separation of the logic for Replay and Make-Connection
  i. Has excellent performance (comparing with RM vs without should have minimal impact when using in-memory)
  i. Has clean, maintainable, well-documented code
  i. Interoperates with Sandesha2, .NET and other implementations of WSRM
  i. Supports persistence and in-memory 
  i. Supports transactions

 * The Rules for Revolutionaries are very useful but may not completely fit this model. In that, there is an assumption that the revolution either replaces the existing code or dies. Neither may happen in which case we will diverge from the RfR.

 * We want to have the discussion in the Sandesha community - the community has a significant proportion of the world's experts on implementing WSRM, and the ideal scenario is that this knowledge gets shared during the design and coding of Mercury. Therefore it is proposed that the discussion happens on sandesha-dev with a prefix of [Mercury] to help filter it.

 * We need to validate the approach with the incubator/legal teams - that it is ok to do a software grant from existing committers into an existing community. This has been done before in the Apache WS project but we should be clear in case the policy has changed. However, this clearly requires that the existing community (Apache WS/Sandesha) is willing to accept the code, so the proposal is to wait until there is agreement on this proposal (or it is kicked out!).


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org