axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: Today's IRC log
Date Tue, 30 Jan 2001 20:53:10 GMT


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.

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.

In any case, this should all be hidden if possible.


> -----Original Message-----
> From: Sam Ruby []
> Sent: Tuesday, January 30, 2001 3:37 PM
> To:
> 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

View raw message