Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xml.apache.org
From: "Anne Thomas Manes" <anne@manes.net>
To: <general@xml.apache.org>
Subject: RE: [POLL] WASP Lite on Apache?
Date: Thu, 15 Nov 2001 09:13:57 -0800
Message-ID: <CJEIKEMEBAONGDDNLEKFKEJBDCAA.anne@manes.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <1005806017.7186.17.camel@dev>
Importance: Normal

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:twleung@sauria.com]
> Sent: Wednesday, November 14, 2001 10:34 PM
> To: general@xml.apache.org
> 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:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org