axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@watson.ibm.com>
Subject Re: JDom
Date Mon, 05 Mar 2001 14:15:04 GMT
Hi Glen,

I seem to recall some work in Xalan along these same lines .. you
may want to check with them and see too what they learnt.

The threading stuff has potential implications for real deployment
(I think). I'm not sure what they are tho, so maybe I should shut
up .. :-).

Sanjiva.

----- Original Message -----
From: "Glen Daniels" <gdaniels@allaire.com>
To: <axis-dev@xml.apache.org>
Sent: Monday, March 05, 2001 9:06 AM
Subject: Re: JDom


> We agree with that intuition, Sam, which is sort of why we adapted this
> model.
>
> There's a bit more detail to the "pull parsing" model.  What we envision
> happening is this.  One thread starts parsing the XML as SAX events, and
> building up a JDOM-like object model.  So basically this guy just creates an
> empty Document "proxy" object, with an almost-empty root Element proxy
> object inside it.  At this point the SAX "StartElement" event for the root
> element has occurred on the parsing thread, and then the thread suspends.
>
> Now when someone calls "getChild('foo')" on the proxy Element (on another
> thread), we figure out a "stop condition" for the SAX parser (you've got an
> element named 'foo', for instance), and then let the parsing thread run to
> that point, building up the fleshed-out object model as it goes.
>
> So the interesting part is that at any point, we can ask the parser
> framework to switch modes and give us the rest of the SAX stream raw,
> without building any more object model.  It just replaces the SAX handler
> proxy midstream with whatever handler we give it, and lets the events run
> out their course.  This way, an (axis) Handler for the body element can
> simply say "doc.getAsSAXStream(myHandler)".
>
> This seemed to be a pretty good compromise between the ease-of-use you get
> with JDOM and the ability to stream if you want it.  We would very much
> appreciate input on this, and I'm writing up a message to send to the JDOM
> development list to see what they think of the idea.
>
> --Glen
>
> ----- Original Message -----
> From: "Sam Ruby" <rubys@us.ibm.com>
> To: <axis-dev@xml.apache.org>
> Sent: Monday, March 05, 2001 8:42 AM
> Subject: Re: JDom
>
>
> > Steve Graham wrote:
> > >
> > > So the sequence would be:
> > >  ---> bytes on the wire
> > >    ---> pull-based SAX
> > >      ---> Java objects (maybe, but not always (eg intermediary))
> > >        ---> make the call (usually)
> > >         ---> Java objects
> > >           --->bytes on wire
> >
> > My intuition is that in the cases where one or both of the headers and the
> > body are likely to be large, the body is the one more likely to be large.
> > Similarly between requests and responses, I would think that it would be
> > the response that would more likely tend to be large.  Anybody care to
> > disagree?
> >
> > If the design point is that the entire response body must be in memory
> > prior to the first byte being output, then all the streaming up to this
> > point will result in only marginal benefits at the cost of a more complex
> > code base.
> >
> > Net: IMHO, if you want to scale, make sure that none of the core function
> > or provided handlers require the bytes of either body to be in continguous
> > memory at any point in the processing.
> >
> > - Sam Ruby
> >
> >
>


Mime
View raw message