Scott McKellar wrote:
I've never used a SAX-style parser, but as I understand it, the idea is to parse the data stream incrementally, and respond to syntactic features as you encounter them. The alternative DOM-style approach is to load the whole thing into memory at once in some kind of data structure, such as a jsonObject.
That's pretty much it. [snip]
What I'm leading up to is the following suggestion. Some kinds of needs might be well met by something like a jsonParseNextSubobject function, and maybe a jsonParseFirstSubobject. Given a pointer to the middle of a buffer somewhere, it would parse until it reached the end of the next subobject and then return a pointer to a jsonObject representing it. In the example of the Houghton-Mifflin extractor, it would extract one book's worth of jsonObject at a time, including whatever lower-level objects were contained therein. Once you were done with a given book you could free it and grab the next one. However I have no idea whether such a thing would be useful in the context of Evergreen -- nor can I claim to know much about what I'm talking about.
The new JSON parser has both DOM and SAX style API's. The DOM API is just a thin wrapper over the SAX core. This makes the DOM internals slightly more obtuse and less efficient, but I'm sure with a little tweaking it can be as fast as a non-SAX implementation. There was no direct purpose for the SAX API when it was developed, but I would like to keep the API intact for potential future use. Currently, no ILS or OpenSRF code is using the SAX API. Mike, your suggestion for replacing SAX callbacks to construct classed objects sounds like a good potential use.
-bill
-- Bill Erickson | VP, Software Development & Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
