|
From: | Vincent Hanquez |
Subject: | Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module |
Date: | Sun, 18 Oct 2009 17:56:55 +0100 |
User-agent: | Mozilla-Thunderbird 2.0.0.22 (X11/20090701) |
Luiz Capitulino wrote:
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 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. :)
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.
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.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.
-- Vincent
[Prev in Thread] | Current Thread | [Next in Thread] |