xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: How to start writing a non-blocking SAX parser
Date Sun, 28 Apr 2002 06:11:31 GMT
Berin Loritsch wrote:

> Miguel A Paraz wrote:
> > On Fri, Apr 26, 2002 at 08:25:11AM -0400, Berin Loritsch wrote:
> >
> >>1) Use-Case:  A Non-blocking parser is used to kick off an XML stream to
> >>    another location.  IOW, we are not using the results of the stream in
> >>    this process.
> >
> >
> > I'm sorry but I do not understand this.
> > What do you mean by 'kicking off'?
> >
> > I'm just going through the stream and calling the content handler in the
> > same way the blocking parse() method does.
> Exactly.  "Kicking Off" == starting process.  The idea is that you
> aren't concerned with waiting for the results because something else
> is handling it.

this is already provided as part of Xerces 2 XNI pull configuration.
(see XMLPullParserConfiguration and http://xml.apache.org/xerces2-j/xni-config.html)

you can also explore APIs that are designed for
XML *pull* parsing (as opposed ot SAX inherent push),
for good start look on recent JavaWorld article:

i have written also driver for my XPP2 parser
that uses Xerces 2 XNI to  implement easy to use XML Pull Parser, see:
so i can can attest that it is not too hard to use
Xerces 2 XNI pull parsing configuration ...

> >>2) Ease of implementation:  We can get the affect of a non-blocking
> >>    parser by running the parse in a background thread.  If we need DOM,
> >>    we use the concept of a Future (starts processing immediately in
> >>    another thread, and only blocks on the first call to the object).
> >>    SAX can be kicked off and left alone.
> >
> >
> > I would like to contain the processing within a single thread and leave it
> > up to clients to do threading if they wish.
> Most clients don't care how things are done, just as long as they don't
> have to mess with the details.
> In essence, you can implement a parser that uses one or more background
> threads, pulling information as it is needed.  You can even have the
> different threads working on multiple streams--kind of like an event
> based architecture.  That would be scalable, and hides the complexity
> from the client.

creation of extra parsing thread is not possible on J2EE platform where
EJB application server controls threading - see for example discussion
of this issue on axis-dev mailing list (they settled for the first version to
not use extra thread with SAX because of those problems).
IMHO it is simply wasteful to have extra thread created for each parsing ...

to avoid wasting time on re-inventing the wheel please look on existing
XML pull wrapper for SAX parsers (http://www.trantor.de/xml/)

> The reason I like JAXP is because I don't have to mess with the details.
> I just tell the ParserFactory that I want a non-validating,
> namespace-aware parser and *poof* I have one.  User simplicity should be
> a desired requirement.

that was the motivation for pluggable and simple to use XMLPULL API,
(API is in spirit similar ot JAXP) for more details please take a look on



In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message