1. I agree that this code should not be in Apache with a org.wso2
package namespace.
2. I don't agree that the timing of this is so bad. There is always a
balance between starting something completely in the open and pushing
a finished object onto the community. When Amila started this, it
wasn't a conscious decision to replace Sandesha2 - it was simply an
experiment. Amila got it to the point where the experiment proved that
this particular approach could work and then brought it to the
community. And I don't think this code is that complete - there is a
lot of work to do on it. To be honest I think there are mixed
messages. On the one hand I'm hearing that its too complete and we
should have engaged the community earlier. On the other hand I'm
hearing that because it doesn't implement 1.1. it still hasn't proven
it can be a cleaner design that Sandesha2. Frankly I don't think there
is any perfect answer here.
3. Apache has a strong history of allowing multiple implementations of
the same thing and I don't see any reason why we shouldn't have two
implementations of RM. Whether or not Mercury is a "replacement" for
Sandesha seems to be something that will only will be decided if the
community wants it to be that way. I think its *way* too early to tell
at this point if Mercury is going to enthuse the community or not. So
far it only implements about half of the features of Sandesha2.
4. I personally think that the right thing to do here is to engage the
community. I think the right way to do that is to move the code to
org.apache.something, and move the discussions to sandesha-dev with a
prefix in the subject like [MERCURY]. This is what we have done time
and again. Either it will engage a wider audience in the design and
implementation or it won't, but unless we do this we can't know.
5. I don't think it really matters whether Sandesha2 has bugs or not.
The question in my mind is whether this new implementation can be kept
cleaner, faster, and more maintainable than Sandesha2. If it can be
then it will gain support, and if not it won't. Its as simple as that.
But I honestly believe in the Apache way, and I don't think it will
end up better without the input of this community, who frankly know
WSRM implementation as well as anyone in the world.
6. I *COMPLETELY* disagree with Ant's point about announcements. This
is a module that works with Axis2 and there is absolutely nothing
wrong with announcing it to the Axis2 community with an [ANN] header.
That would be true if this was a commercial extension to Axis2. But
this is an Apache Licensed open source project. Further, a version of
this code has been donated to Apache. So unless I have somehow an
utter misunderstanding of Apache's mailing lists I cannot see any
reason at all not to post this announcement.

Paul

On Tue, Jun 3, 2008 at 9:18 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <[EMAIL PROTECTED]>
>> wrote:
>
> <snip>
>
>>
>> > While that may be true, I'm disappointed that the work moved so far
>> > forward before being brought to the Sandesha community, and I would
>> > *really* like to find some navigable path that brings us eventually to a
>> > single implementation of RM-over-Axis2, in Apache.
>
> Agree with that completely, this seems a really sad thing to have happened.
> Is there really no way to get Sandesha working with SecureRM over SMTP,
> there didn't seem to be much discussion about what the issues are with doing
> that?
>
> While things are as they are I do think things like Mercury announcements
> should be kept off the Apache mailing lists, so no more posts like:
> http://apache.markmail.org/message/ounhpi54rx543vqw
>
>    ...ant
>
>



-- 
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]

Reply via email to