Anthony Liguori wrote:
Vincent Hanquez wrote:
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).
We need two sets of extensions for use within qemu. Single quoted
strings and varargs support. While single quoted strings would be
easy to add to any library, vararg support is a bit more tricky as you
need to carefully consider where you pop from the varargs list. A
simple sprintf() isn't sufficient for embedding QObjects.
care to explain what's a single quoted string and varargs support means
in your context ? (just a simple example you do maybe ?)
When generating on-the-wire response traffic, we shouldn't use any of
the extensions so it will be 100% json.org compliant.
great.
I'm pretty sure if you tried to duplicate the functionality of my
patches, it would be much more than 50 lines. That's not saying it's
a better json parser, just that we're looking for very particular
features from it.
Since it doesn't appears to be linked to json particularly, I don't
understand why it's a feature of the parser though.. and then any parser
could grow the support you need on top of the parser couldn't they ?
--
Vincent
