Hi Amila,

I have to correct something related to your previous post. This has nothing to 
do with the Mercury effort.

You mentioned,
AFAIK  Sandesha2 has also started as an Axis2 module by Chamikara.  Then people 
has joined and contributed to it at various times.

It was not like this. When we design Axis2, we all (most of the axis devs) 
discussed the architectures for various modules such as Sandesha. Everybody was 
in agreement with the high-level details of the implementation as well. 
Chamikara and others (Sanka, me ....... (I am sorry if I miss anybody )) 
contributed to the initial code. Then Chamikara pushes it alone and later lot 
of devs joined the effort.

So, when there is a need people will jump in and I believe that it will the 
same for Mercury as well. As the starting point, I would like to know the 
architecture that you propose for Mercury. (This is not the simulator based 
architecture  but how mercury is implemented as an Axis2 module, the handlers 
to be deployed, message receivers to be used etc...) 

Thanks,
Jaliya


----- Original Message ----- 
  From: Amila Suriarachchi 
  To: David Illsley 
  Cc: [email protected] 
  Sent: Friday, June 13, 2008 4:04 AM
  Subject: Re: [DISCUSS] Mercury Proposal





  On Thu, Jun 12, 2008 at 9:32 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),

  definitely we have to remove the persistence module and re write it using 
direct JDBC. May be the first step to do if it going to apache. If we think 
that Mercury without that part, Then this problem is already solved.


    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.

  AFAIK  Sandesha2 has also started as an Axis2 module by Chamikara.  Then 
people has joined and contributed to it at various times. Same thing may happen 
with the Mercury with the time. As Chamikara did with Sandesha2 I can initiate 
it with a new design. But this does not mean it will be a one man show for ever.

  thanks,
  Amila.



    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]





  -- 
  Amila Suriarachchi,
  WSO2 Inc. 

Reply via email to