Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module

[Luiz Capitulino <lcapitulino@redhat.com>]

On Sun, 18 Oct 2009 16:06:29 +0100
Vincent Hanquez <vincent@snarc.org> wrote:

> 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".

 No lines is a lot better than 50. :)

 The real problem though is that the parsers I looked at had their own
"object model", some of them are quite simple others are more sophisticated
than QObject. Making no use of any kind of intermediate representation like
this is a feature, as things get simpler.

 Also, don't get me wrong, but if we would consider your parser we
would have to consider the others two or three that are listed in
json.org and have a compatible license.

> 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).

 This is already settled, I hope.