On Thu, 2001-11-15 at 09:13, Anne Thomas Manes wrote: > 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.
Good. That's very sensible. > 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] --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
