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
