axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Re: IRC Log of 2001-04-03 SOAP Chat
Date Wed, 04 Apr 2001 04:28:24 GMT
<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 fine.

+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


Mime
View raw message