Hi Glen, This is a difficult situation, and one that's made more difficult by the amount of code that already exists.
I would take exception to you saying that Sandesha2 doesn't support secure, asynchronous scenarios. It does, and I've seen the results of interop testing with WCF (for example) with those scenarios. I understand that there have been problems using Sandesha2 with SMTP and the RM 1.0 replay model - both underspecified areas, so to be honest that's not a surprise. If the problems extend beyond a problem in a particular customer environment, I'd really like to know what they are so we can fix Sandesha2. That said, I'd agree that Sandesha2 is complex :-) and that we'll need a follow project at some point. Right now, I think that Mercury is heading the wrong direction to be that follow on project - It's based on the requirements of a single customer using esoteric and back level specifications, and takes, in my opinion, many of the same design decisions from Sandesha2 which resulted in the complexity of Sandesha2. As I've said before, I think we're still a while away from having enough shared production experience to get the building blocks of the next generation of Sandesha right. I do recognise that Mercury is a necessary tactical solution for WSO2 to satisfy a particular customer, and I'm not criticising that move - it's probably the right move for WSO2 as a business, I just don't think it's the right move for Apache. That said, no-one has objected to a revolutionary branch, but clearly that does place limits on what/how WSO2 can release... not entirely sure what the best options for that are... perhaps repackaging before release... eclipse would probably make that easy enough. I'm more than happy to continue this discussion on list or have an IRC or telecon if more of a real-time discussion is needed. David On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <[EMAIL PROTECTED]> wrote: > (sorry for the late response) > > Hi Sanjiva, all: > > Sanjiva Weerawarana wrote: >> >> David, just to be clear .. the only reason we went down a new impl path is >> because we had SUCH a terrible time getting Sandesha to interop over SMTP, >> which is a crucial requirement for this customer. SecureRM over SMTP was >> just not working out :(. > > 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. Having two > implementations, whether both in Apache or elsewhere, does two things, > neither of which are good - 1) it confuses the user base 2) it > splits the cycles of the active development community, when everyone > could be cooperating. > > As I see it right now we have two implementations, both of which have > flaws. Sandesha is extremely complex, and clearly can't handle > some critical secure and asychronous scenarios. Mercury is new, untested > (in the real world), and has potential architectural issues as mentioned by > David (lack of 1.1, lots of synchronized methods, etc). The quicker we can > get to the point where we've settled on one, the better able we'll be to fix > the flaws. > > So here's a strawman for what we *might* do here, with at least one open > issue: > > * Get the Mercury code over to the Sandesha SVN, in a revolutionary > branch exactly as dims suggested, and continue all work there for now, so > that the Sandesha team can a) see the work, and b) contribute to it if they > desire. > > * WSO2 clearly needs to be able to continue doing releases of this code, so > I guess we should leave the package names org.wso2... for now. This means > a) org.wso2 code in Apache svn (I think there's precedent for that kind of > thing), and b) releasing stuff based on code in an unofficial branch. > > --- OPEN ISSUE - I *think* this is ok, but we need to confirm (should we ask > legal-discuss?). We wouldn't be doing *Apache* releases, mind you - we'd > just be taking a copy of the code from the Apache SVN and > releasing/supporting it under the auspices of WSO2. > > * Without being presumptive, we continue work on Mercury with the hope that > the Sandesha community will eventually accept it as Sandesha.next (whatever > it's called, we all move to working on that code). This involves > conversations and almost certainly some refactoring, but if everyone > involved starts off with the goal of a single implementation and remains > open to input, we can hopefully get there - maybe this looks like Mercury > with some fixes/changes, and maybe this looks like Sandesha with some > fixes/changes, I don't know yet. > > * Eventually either a) we EOL Sandesha and move to Sandesha3/Mercury as the > Apache-provided RM implementation over Axis2, or b) we find we're at > loggerheads and can't come to a consensus, at which point we declare defeat > and continue with two separate implementations. > > Dealing with forks/merges like this is never an easy process, but the > results can be well worth it for both the developers and the users. I'd > like to try it. What do you think? If we don't have real commitment on > both sides to get it happening, it's not going to work, so please consider > this when replying. > > Thanks, > --Glen > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
