Andreas Veithen wrote:
On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <d...@sosnoski.com> wrote:
...
The nice thing about using a slightly-hacked and simplified DOM is that
everything would be automatic - as it is with Axiom now, but with
considerably less memory and processor overhead (because this approach would
*only* defer building the DOM representation of the Body content, and would
build the entire Body content as a DOM whenever anything within the Body was
accessed - a lot of the memory and processor overhead of Axiom relates to
the incremental one-element-at-a-time build process). And because it'd still
implement the DOM interface (or at least a subset suitable for use by WSS4J)
applications using WSS4J could choose to use this or continue to use any
other DOM they want.
Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.
Yes, I can see that it'd be possible to implement a deferred
parsing/building approach at the element level without much added memory
or processing overhead, if done correctly. There can really only be one
parser in use, for instance, so that can be stored at the document
level, and even the element currently being expanded could be stored at
that level (rather than using a flag on the element). But is the
flexibility gain from doing things this way worth the added complexity,
as opposed to my suggestion of a tweaked DOM with a special kind of
expandable Element used only for the Body (well, actually two kinds of
expandable Elements, the second to handle MTOM attachments)? I don't know.
- Dennis
