Luiz Capitulino 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".
No lines is a lot better than 50. :)
well it all depends on how you see thing; whilst i'm happy to help all
sort of integration (qemu in this case), my library has been made for
integrating with absolutely any object model. so 50 lines seems like a
win to me, because I could do the same thing on a project that use glib,
or some QT model using exactly the same engine. Hence the reason why i'm
packaging it as a .a/.so library. (not that I particularly object to an
embedded use case too).
I think that's a win in the end when people can just reuse wheels
instead of designing new one for catering for special needs.
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.
most of the parser there are either, weirdly licensed, have an object
model integrated with it, are not interruptible,
or are quite complex for no apparent reason; I carefully read all of
them, before choosing to reimplement one from scratch.
--
Vincent
