More background: As Sam said earlier, two Systinet (formerly Idoox) developers are committers on the Apache SOAP projects. The reason we elected to go off and develop a separate code base was purely for timing reasons. We wanted to release production-ready products as quickly as possible. We didn't think that Apache SOAP would serve our purposes, and we didn't think we could wait for Axis. So we designed our own. We released our SOAP stack in September, and we're building additional products based on that implementation.
But we're not tied to our own SOAP stack. We designed the WASP product line to be SOAP stack-agnostic. We are prepared to rip our SOAP stack out and replace it with another SOAP stack if/when appropriate. We think it's pointless to fight over a SOAP stack. The SOAP stack should be a part of the underlying fabric. What's important is that there is one, and the one that's there is reliable, performant, feature-rich, flexible, and extensible. Our primary goal is to get a really strong, pervasive SOAP stack that fully supports JAXM, JAX/RPC, a complete implementation of SOAP Section 5, support for SOAP 1.1 and SOAP 1.2, pluggable transport protocols, etc. I think it's a good idea that we formalize a plan to integrate the code bases. Anne > -----Original Message----- > From: Theodore W. Leung [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 14, 2001 10:34 PM > To: [EMAIL PROTECTED] > Subject: Re: [POLL] WASP Lite on Apache? > > > On Wed, 2001-11-14 at 14:14, Sam Ruby wrote: > > Theodore W. Leung wrote: > > > > > > I am *very* against the idea of WASP as a separate project. > If the Axis > > > and Wasp communities can not agree, then I think we're done. > > > > What if the Axis and Wasp communities agree that separate code bases are > > the right initial step? > > I was stating my opinion -- if the Axis and Wasp communities decide that > separate code bases is the right thing, then of course I respect that -- > I would suggest in that case that there be some visible plan for how > those code bases integrate. > > > > I think that the WASP code and community can contribute in a number of > > > areas. The way that we got into the Crimson / Xerces mess was that we > > > said, we'll accept both projects and figure out how to merge them > > > later. It took a long time for that to start to happen -- > not that it's > > > fully happened just yet. > > > > Let's not extrapolate too much from one data point. I would > suggest that > > there were other factors involved too. > > Yes there were. And some of them apply here too. Namely Sysinet and > IBM both having investment in existing code bases. > > > > The way that Batik happend > > > > If I understand correctly, Batik was "x" number of companies > getting their > > code integrated outside of the scope of Apache, and then > contributing the > > result? > > correct. > > > Given that Axis is already an Apache code base, how should we > > proceed? > > > I'd be very happy to see a JAX RPC and JAXM compliant SOAP stack on > Apache. If the Wasp stack turned out to be closer, would the Axis > community be willing to orphan the Axis code base and do the work to > bring the Wasp stack up to spec? If the Axis stack turns out to be > closer, are the Wasp folks willing to drop the Wasp stack and adapt the > rest of Wasp to Axis? > > I can live with two code bases for a defined period of time. What I > would not like to live with is an uncertain direction and/or unbounded > timeframe for those two code bases. I think that in the end there needs > to be a single SOAP code base, and that part of the process for the > contribution should be a reasonable plan for how to get there. > > Ted > > > > --------------------------------------------------------------------- > In case of troubles, e-mail: [EMAIL PROTECTED] > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
