axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: IRC Log of 2001-04-03 SOAP Chat
Date Wed, 04 Apr 2001 04:38:51 GMT

In all sincerity...

You rock.  :) :)

This all completely makes sense, I agree 100%, and I'm totally jazzed about
moving this process forward.


----- Original Message -----
From: "Sam Ruby" <>
To: <>
Sent: Wednesday, April 04, 2001 12:28 AM
Subject: Re: IRC Log of 2001-04-03 SOAP Chat

> <GlenDaniels> I'd much rather this stuff was on the table.
> <GlenDaniels> If there's some good technical reason not to use JDOM, then OK
> +1
> Lets put a few things on the table.
> In the context of this project, IBM can be viewed as a customer.  And the
> currency with which this customer pays is in investing some of its valuable
> developers time.
> There are some people at IBM who helped WRITE the specifications that
> became the standard.  There are some people at IBM who invested a lot of
> time and energy to produce implementations that conform to those standards.
> Furthermore IBM has been telling its customers for some time that they can
> depend on these standard interfaces being there, and much of the IBM
> infrastructure that is built on top of this code depends on these
> standards.
> So, understandably, there are some IBMers with strong opinions on the
> subject.
> This being said, I am quite prepared to ignore them.  On two conditions.
> We are right.  And we can prove it.
> IBM as a customer is very unhappy with the current performance of xml-soap.
> IBM as a customer would be delighted if this problem can be solved within
> the bounds of the current W3C standards.  IBM as a customer would be
> delighted if this problem can be solved with the current Apache code bases.
> I believe these goals and concerns are in line with Apache's.  Anybody want
> to disagree?
> But if we as Apache developers exhaust all avenues and come to the
> conclusion that the performance problems can't be solved adequately without
> breaking one of the above constraints, then IBM will simply have to figure
> out some way to deal with the breakage.  If this is what comes to pass,
> expect some push back - enough to verify that we are SURE that such
> breakage is necessary.
> The way to proceed is to define and validate some scenarios.  I think about
> three should do it.  Pelting a server with lots of tiny and quick messages.
> Processing a typical in size but deviant in content message (e.g.,
> convoluted hrefs).  And dealing with mondo messages.  The above are off the
> top of my head - if somebody has some real live customer usage data, that
> would be much preferred.
> Once that is done, we proceed openly and based on what the results of the
> above tests shows us.  Meanwhile, if necessary, we become customers from
> hell for the various XML parser implementations.  ;-)
> Those that have watched me here know that I am a consistent advocate of
> making these decisions out in the open.  This is not going to change.
> Come July I will have been with IBM for 20 years - yes twenty years.  I
> could tell you what my title is, but I'm not sure it would be meaningful to
> people outside of the company, but suffice it to say that I have earned
> enough respect that when I speak many people listen.
> Meanwhile, I need some hard data, so I'm going to go back to coding up my
> test.  I'm focusing first on pelting with lots of small messages...
> - Sam Ruby

View raw message