Luiz Capitulino wrote:
it got a raw/pretty printer, an interruptible parser (on the same idea
as JSON_parser.c), it's faster than JSON_parser.c [1],
it's completely generic (more like a library than an embedded thing),
fully JSON compliant (got a test suite too), support
user supplied alloc functions, and callback for integer/float doesn't
have their data converted automatically which means
that the user of the library can use whatever it want to support the
non-limited size JSON number (or just return errors for user that want
the limit).
the library by itself is 39K with -g last time i've looked.
Integration with QObjects is a killer feature, I think it's the
stronger argument against grabbing one from the internet.
I can't think of any reason why integration with qobject would take more
than 50 lines of C on the user side of the library.
since the API is completely SAX like (i call it SAJ for obvious reason),
you get callback entering/leaving object/array
and callback for every values (string, int, float, null, true, false) as
a char * + length. for exactly the same reason, integration with glib
would take the same 50 lines "effort".
note that FTR, obviously i'ld like to have my library used, but i'm
happy that any library that is *fully* JSON compliant is used (no
extensions however since you're obviously loosing the benefit of using
JSON if you create extensions).
--
Vincent
