SAX2 streaming input?

[Christopher McGee <Mc...@iticentral.com>]

My problems is that I want to stream data into the Xerces SAX2 parser as
well as getting the events streamed out.  

I have multiple XML streams coming in to my application and being serviced
by one process.  I want to have one Xerces-c parsing object instantiated per
XML stream.  As data comes in on a stream, I want the servicing process to
be able to hand the XML data off to the appropriate Xerces-c instance.  Each
chunk of data coming in on a stream will be a piece of a whole XML file.  

My problem is that the SAX2XMLReader only has the method parse() which takes
a complete XML file (in a file, in memory, or at a URI), not anything like
parseNextChunkOfData().  I could make a new InputSource that blocked waiting
for the next chunk to become available, but then I would have to spin up a
new thread for each stream I had, which I would really like to avoid (we
have more streams then we have threads available currently).

So basically what I need is for the SAX2XMLReader not to block waiting for
the rest of the data to be available from the InputSource, but instead to
return to the calling method.  This would mean that the SAX2XMLReader would
have to maintain its state between calls to parseNextChunk() and be able to
pick up where it left off.

My questions are, is this already handled somehow by Xerces-c?  If not, what
is your guess at how hard this would be to add to Xerces-c?  If it does not
seem like a total rewrite I will look into adding this to the code myself. 

Thanks,

Christopher McGee
mcgee@iticentral.com

Re: SAX2 streaming input?

[Dean Roddey <dr...@charmedquark.com>]

Look at the MemBufInputSource class, and the MemParse example which shows
how to use it. These are examples of how you can create your own input
sources (and associated input streams.) If you want to write an asynchronous
input stream, you'd just create a MyAsyncInputSource and
MyAsyncBinInputStream class, and use those to feed the parser. These can do
anything they want. Basically the input stream class just has a single
virtual, which you implement, which says "give me more data". If you want
that to block and wait for more data, that's fine. The parser will just be
blocked until you return with more data. When the end of that document
arrives, just return with zero bytes to indicate that the end has been
reached. The next time it calls, start feeding it data from the next
available document.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"I'm not sure how I feel about ambivalence"


----- Original Message -----
From: "Christopher McGee" <Mc...@iticentral.com>
To: <xe...@xml.apache.org>
Sent: Wednesday, March 07, 2001 2:06 PM
Subject: SAX2 streaming input?


> My problems is that I want to stream data into the Xerces SAX2 parser as
> well as getting the events streamed out.
>
> I have multiple XML streams coming in to my application and being serviced
> by one process.  I want to have one Xerces-c parsing object instantiated
per
> XML stream.  As data comes in on a stream, I want the servicing process to
> be able to hand the XML data off to the appropriate Xerces-c instance.
Each
> chunk of data coming in on a stream will be a piece of a whole XML file.
>
> My problem is that the SAX2XMLReader only has the method parse() which
takes
> a complete XML file (in a file, in memory, or at a URI), not anything like
> parseNextChunkOfData().  I could make a new InputSource that blocked
waiting
> for the next chunk to become available, but then I would have to spin up a
> new thread for each stream I had, which I would really like to avoid (we
> have more streams then we have threads available currently).
>
> So basically what I need is for the SAX2XMLReader not to block waiting for
> the rest of the data to be available from the InputSource, but instead to
> return to the calling method.  This would mean that the SAX2XMLReader
would
> have to maintain its state between calls to parseNextChunk() and be able
to
> pick up where it left off.
>
> My questions are, is this already handled somehow by Xerces-c?  If not,
what
> is your guess at how hard this would be to add to Xerces-c?  If it does
not
> seem like a total rewrite I will look into adding this to the code myself.
>
> Thanks,
>
> Christopher McGee
> mcgee@iticentral.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>