A SaxParser notification

[HackerBaloo]

We need to get a notification from the SaxParser, to be able to add authentication to our current changeSet parsing. To avoid having to read the whole changeset into memory, we want to run the work in parallell a chunk at the time.

To accomplish this we would need a notification from the ParseEngine.

I'm thinking about adding a SaxParser::setParserObserver(ParserObserver* observer)
after every call to XML_Parse in ParseEgine the observer should be notified.
Do you like the feel of it, or would you suggest a different approach?

class ParserObserver
{
public:
//A parsed length of zero indicates parsing finished.
virtual OnParsed(const char* pBuffer,std::streamsize parsedLength) = 0
}

[alex]

I could be missing something, but is there a reason ContextHandler does not work in your case?

[HackerBaloo]

Yes the contentHandler doesn't work in our case, but I considered, as an alternative, to add an extra notification from the contentHandler. But the implementation I suggested keep the contentHandler clean from our perhaps, somewhat special, needs.
The reason the contentHandler doesn't fill our needs really needs an whiteboard to explain, but I will make a try.
Two treads interested in the same stream istream, and a memory constrained environment.
Each thread run a SaxParser on the stream.
The SaxParser tries to read 4096 bytes into it's buffer.
If I would use some of the contentHandler notifications I would not know when the buffer has been used. So then I would have to copy the data to another buffer, and I would not have control over the size of the buffer either.
Now I just reuse the SaxParserBuffer to feed the second stream.
My solution: Thread1 eats a chunk from a socket stream into the SaxParser, signals - DataAvailable and waits for the Consumed event.
Thread2 waits for DataAvailable - consumes a Chunk from Thread1-SaxParser buffer into Thread2-SaxParser buffer, sets the Consumed event...

[alex]

Sounds like the cleanest solution would be to create your own handler (see DefaultHandler), perhaps in conjunction with Poco::TeeInputStream.

Given that your request is rather specific, at this time it does not appear to warrant a library-side modification. If you still feel it does, you may try to elaborate on the case and submit it as a feature request on SF and someone will look into it eventually.

[HackerBaloo]

I got an answer from Günter, that I first thought solved my problem. But then I realized that I forgot an importantant part in my explanation.
Thread1 should always do it's work in this server, that is, parse and authorize the stream.
But thread two has the choice to either parse and act on the stream, or just send the stream to another server...

Günters suggestion, which was perfect for the one server scenario:
Hi Björn,

I have followed the discussion in the forum regarding this issue.
From the limited information I know about your problem, I wonder why you need two separate threads parsing the same XML file simultaneously.
Given that you cannot parse in parallel anyway (the second thread can only parse the buffer's content after the first has finished), why not simply create a special ContentHandler that forwards all events to the two different ContentHandler instances you're going to use, like:

class MultiContentHandler: public Poco::XML::ContentHandler
{
public:
MultiContentHandler(ContentHandler* pFirst, ContentHandler* pSecond):
_pFirst(pFirst),
_pSecond(pSecond)
{
}

void startDocument()
{
_pFirst->startDocument();
_pSecond->startDocument();
}

// ...

private:
Poco::XML::ContentHandler* _pFirst;
Poco::XML::ContentHandler* _pSecond;
};

This way you only need one parsing thread, but can feed two (or even more) ContentHandler's with the same content.

Just my two cents...

Günter