feature request: sax push parser about ox

[ohler55]

Please explain what you mean by a sax push parser. I believe the current Ox SAX parser is what is sometimes referred to as a push parser.

[notezen]

I mean that now we did not have http://nokogiri.org/Nokogiri/XML/SAX/PushParser.html analog

[ohler55]

It look like that takes is just a standard SAX parser. I don't see the difference between that and the Os::Sax parser other than the handler is created inline. Am I missing something?

[notezen]

Main feature of push parser is that we push new incoming data to parser instead of situation when we let parser read data from IO stream directly. It is useful in event-processing code (eventmachine library for example).
Code example:
p = PushParser.new(sax_handler)
p.push '<chi'
p.push 'ld>some con'
p.push 'tent'

where sax_handler object with methods such as 'start_element','end_element', 'text' and so on.

[ohler55]

I understand. Basically it parses a stream until the stream closes.

[ohler55]

Look for a continuous SAX parser in some future release. Now that I understand what you were asking for it makes a lot of sense and would be ver useful.

[Zapotek]

I just found myself in need of this feature as well.

[Zapotek]

Not very efficient but does the job:

buffer, buffer_in = IO.pipe

handler = MySAXHandler.new

Thread.new do
    Ox.sax_xml( document, buffer, sax_options )
end

buffer_in << '<parent><chi'
buffer_in << 'ld>some con'
buffer_in << 'tent</child></parent>'
buffer_in.close

# Do stuff with handler

[ohler55]

I prefer that over cooking something into Ox that does the same thing as a stream or pipe. You might be surprised how efficient it is.

[Zapotek]

Creating threads isn't efficient for this, for example in my case this can be called hundreds of times in series leaving me with that many short-lived threads which has substantial impact on resource utilization and performance.

Pushing directly to Ox seems like the cleaner way and push parsers are an established paradigm.

[ohler55]

Another approach would be to keep a longer running thread that services parse requests. This feature will take some time to get done. Right now the state of the parser is on the stack and not carried around in a ruby object. That would have to change for the parser to be reentrant. The solution may be to keep a thread in C to maintain the parser state but I have no idea what problems that would cause for Ruby.