ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: JDOM vs DOM (was: Re: IRC chat log)
Date Wed, 01 Nov 2000 22:06:28 GMT

> The problem with DOM is (mostly) the implementation. The APIs 
> are designed
> to support "live" edits and monitoring, so the API force certain impl
> requirements too. The real problem is the performance (memory usage)
> of a full DOM impl *when one is not needed*. I would argue 
> that Apache SOAP
> is a case where a full live impl is not needed: once the 
> envelope is parsed
> its not going to change while a filter is operating. 

Hm... I don't believe that's actually the case.  What about filters
(MessageHandlers, Transcoders, whatever :)) which do, for instance,
decryption of the Body?  I think in the general case, we will in fact want
write access to the tree.
> The solution IMO is to use SAX as appropriate and an efficient impl of
> the DOM that is customized for our needs. What I am opposed 
> to is exposing 
> a non-standard API, even if it means a performance hit. Let's 
> be realistic,
> JDOM vs a good DOM will not mean a 50% performance difference not 
> reasonable sized messages. For large messages, the *only* 
> real option is
> to use SAX. Anything else is nuts. 

Sure.  But what I'm talking about is the question of what internal
representation we're going to store stuff in.  In other words, let's take
the example we've been discussing where the SAX parser is happily munching a
message, processing what it can in an event-based way.  Now we hit an IDREF
during deserialization of a header which points to an independent element
later in the document.  We need to run the SAX parser until it hits that
element, sucking the XML up into some sort of data structure.  We could just
use Xerces (or some other) DOM for this, which would be fine.  But if
there's a more efficient way, we might want to investigate it.


View raw message