[OPEN-ILS-DEV] PATCH: osrf_json_object.c (tweaks)

[Bill Erickson]

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: erickson at esilibrary.com
| web: http://esilibrary.com