|
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 -----
Sent: Friday, June 13, 2008 4:04 AM
Subject: Re: [DISCUSS] Mercury
Proposal
On Thu, Jun 12, 2008 at 9:32 PM, David Illsley < davidillsley@xxxxxxxxx> wrote:
On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle < pzfreo@xxxxxxxxx> 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.
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"
--
Amila Suriarachchi,
WSO2 Inc.
|