axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <NAKAM...@jp.ibm.com>
Subject Re: RE: Today's IRC log
Date Wed, 31 Jan 2001 05:37:54 GMT

Glen,
Comments inline:
Regards,
yuichi

>Sam:
>My concern with SAX is that the processing model can (and should, IMO, to
>get the real bonus) be *completely* different from the DOM model.  I would
>want to build the Handler framework differently - basically have each
>Handler register for the types of stuff it's interested in, and then a
piece
>of our infrastructure acts as the SAX event handler, feeding the pieces to
>the appropriate Handlers as they are read.  This has some problems with
>multi-ref accessors, as we discussed in the chat, so there would still
need
>to be *some* kind of generated in-memory message model.
Agreed.

>I can see us, for now, making the DOM completely isolated behind a
canonical
>Message API.  That solves the "option, not a requirement" problem.  Then,
if
>we have time, I would suggest we consider a PDOM approach, with a thread
>spinning off SAX events to a middle layer which presents the canonical
>Message API upwards to the Handlers.  When they ask for stuff that hasn't
>yet been reached in the stream, the PDOM layer runs through the SAX
stream,
>caching everything until it gets to the desired stuff.  This would allow
us,
>later, to hook the SAX events to other sinks when appropriate.
PDOM is cool, but is not standard, and not implemented (Right?).
Hopefully, if PDOM is donated to Xerces, we will happy to use it.
The idea here is a good integration of DOM/SAX/Stream approaches.
But on the other hand, this kind of mechanism has been implemented
in Xerces already.  (i.e.  All DOM entities are NOT created at the parsing
time,
rather they are created by demand-driven way)
One more question is: Where is the real performance bottleneck in our
engine?
We have SOAP V2.1.  Have anyone checked its perfomance?  We may have
other crucial bottelneck for which the optimization here is nothing.

>In any case, this should all be hidden if possible.
>--Glen
>
>> -----Original Message-----
>> From: Sam Ruby [mailto:rubys@us.ibm.com]
>> Sent: Tuesday, January 30, 2001 3:37 PM
>> To: axis-dev@xml.apache.org
>> Subject: Re: Today's IRC log
>>
>>
>> +1.  I generally agree with everything that was said.
>>
>> A few comments:
>>
>> (1) I agree that rewrites are inevitable, as some point in
>> the future we
>> will know more than we do now.  But that is no excuse to
>> ignore things that
>> we DO know now.
>>
>> (2) while in the general case, there may be some handlers or even some
>> specific messages that are difficult/impossible to handle without
>> significant lookahead, coding everything to the general case will make
>> everything uniformly slow.  Put in a more tangible way - inevitably
>> somebody will develop and publish benchmarks claiming that
>> their version of
>> SOAP is better performing and more scalable than ours.  Such
>> benchmarks are
>> likely to be very simple messages, though possibly large,
>> messages arriving
>> at a fast rate.
>>
>> For these reasons, I believe that DOM should be an option, not a
>> requirement.  In the fullness of time, SAX and/or pull may
>> also be valid
>> options, though in order to validate the architecture, at least one
>> alternative that is significantly different than DOM (more so
>> than simply
>> JDOM is) should be implemented.
>>
>> - Sam Ruby
>>


Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413


Mime
View raw message