axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Radovan Janecek" <jane...@systinet.com>
Subject Re: WASP & Axis
Date Wed, 05 Dec 2001 12:45:44 GMT
timeframe:
----------
I know that it is not easy to make a guess without seeing the code. On the
other hand, there is a lot of WASP documentation: architectural concepts,
open APIs, etc. My knowledge of Axis is also based on playing with the
demos, using the API rather than digging in the code itself.

cooperation:
------------
If I understand you correctly, you basically agree with the idea of
standalone Apache WASP project (any Axis dependence). And later on,
establishing new soap project (probably from the scratch) that will use the
best from both projects...

name of the new project:
-------------------------
I have no problems with the Axis name for the future project. I like it. I
have also an experience with changing the name - you probably remember the
IdooXoap product. :-)
I just didn't want to dump our code to Apache cvs and call it Axis-wasp (or
any similar) because it would be misleading.

WASP for C++:
-----------------
It is written in very portable way. In fact, it uses only classes from C++.
No templates, no exceptions, etc. Sources for the older (IdooXoap-like
version) are available on our website. Sources for the new (WASP-like)
version will be available soon. We have lot of C++ users and I'm pretty sure
that C++ version is even better Apache candidate than the Java one.

my summary:
-------------
I think that the ideal case would be
1) Establishing separated CVS for Apache WASP (or module, or whatever - I
don't know Apache processes).
2) We will start with opensourcing WASP C++ because there is nothing similar
on Apache yet. Doing this, we will learn the formal and informal community
processes, etc.
3) We will further discuss and plan with the Axis team possible cooperation
on the Java side. We will dump WASP for Java to the cvs at some point and
continue with the development. It cannot be done immediately, since the code
requires some adjustments before it is opensourced.
4) When we all decide to start 'Axis 3', Java WASP will switch to
maintenance mode only and all the effort will be focused on 'Axis 3' only.
5) The question is whether WASP C++ will be also called Axis 3 then. Likely
yes.

There are also other questions in my mind, but maybe it is enough for now.
I'd like to hear your and other Axis developers opinions on this. I can
easily imagine that Axis developers won't be happy with starting new 'Axis
3' project in the near future just because Systinet offers its framework to
Apache. :-)

Sincerely

Radovan


Radovan Janecek
VP, Engineering, Systinet  (formerly Idoox)
http://www.systinet.com



----- Original Message -----
From: "Sam Ruby" <rubys@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Tuesday, December 04, 2001 2:33 AM
Subject: Re: WASP & Axis


> Radovan Janecek wrote:
> >
> > Hello all,
>
> Hello Radovan!  Long time no see!
>
> > However, I feel there are other serious questions we should discuss
prior
> > doing any merging effort:
> >
> > timeframe
>
> It is hard to discuss timeframe without seeing the code.  In a perfect
> world, one would be obviously better and plug compatible; but clearly that
> won't be the case so the discussion is likely to be messy for a while.
>
> > ways to cooperate
> >
> > Since I think that Axis and WASP are pretty incompatible, I definitely
> > prefer the third option. I'm convinced that it is the best one at least
from
> > the technical point-of-view. Is the 'Xerces and Crimson' case a good
example
> > of the third option?
>
> Xerces and Crimson is a perfect example - both of what we want to avoid
and
> what will ultimately be the right course.
>
> For the longest time, Xerces and Crimson had an uneasy coexistance
> externally, but internally, they had a bitter relationship.  Essentially,
> all of the developers of Xerces were from one company, all of the
> developers of Crimson were from another.  Both sides could provide ample
> "evidence" that it was the other side's fault.
>
> Fast forward to the present.  Xerces 1 and Crimson are both essentially in
> maintenance mode at the present time.  The active code base is Xerces 2.
> The new design was jointly produced by a common team.  The implementation
> bears little resemblance to either code base - but incorporates important
> lessons learned from both.  The one thing that was vitally important was
> that the name of the code base with the most name recognition associated
> with Apache lived on.
>
>  = = =
>
> We broke that rule of successors keeping the same name here in Axis, and
we
> have suffered for it.  I don't know if you recall, but I argued weakly for
> keeping the name SOAP, but agreed to abide by the consensus.  For the
> longest while I argued strongly that we should call this release V3, but
> over time, stopped that.
>
> I take responsibility for allowing this rule to be broken.  The name SOAP
> had little support from the PMC, by the development community, or even by
> the W3C at the time.  But in hindsight, I should have stood firm.
>
> When you stop and think about it, it is silly that we as professional
human
> beings assign so much importance to the name, but again and again
> observation of behavior indicates that the name is the most important
> aspect of community.  Just like people will go to war over flags, you will
> see that there are people here who cling on to the notion that there is a
> separate SOAP community.
>
>  = = =
>
> It pains me to bring up the above as it is likely to reopen old wounds.
> But the lesson is clear.  The successor to Axis should be named Axis 2 (or
> if I had my druthers, Axis 4 or perhaps even SOAP 4).  From a technical
> perspective, the code base may bear little internal resemblance to the
> current code base named Axis.
>
> Another example that we can draw upon - the "Catalina" revolution in the
> Tomcat base.  It originally resided in the same CVS tree, got split out to
> a separate cvs tree, and anointed with the name Tomcat 4.  Now there is
> some activity factoring out common code into a "commons" area.  If we
> follow down similar footsteps here, I see the possibility of there being a
> separate "Web Services" project, with multiple subprojects focusing on
> individual areas.
>
> > WASP for C++
> > ----------------
> > You probably know that Systinet also has a WASP for C++ too. It has the
same
> > architectural concepts as WASP for Java. I think it is perfect candidate
for
> > opensourcing on Apache as well. What do you think?
>
> There is high demand for a cross-platform C/C++ implementation of SOAP.
It
> would likely do very well here.  And if it's architectural concepts were
> similar to the Java implementation that you are proposing
>
> - Sam Ruby
>


Mime
View raw message