From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzZ4t-000430-Cv for qemu-devel@nongnu.org; Sun, 18 Oct 2009 12:57:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzZ4o-00042P-Vj for qemu-devel@nongnu.org; Sun, 18 Oct 2009 12:57:55 -0400 Received: from [199.232.76.173] (port=32952 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzZ4o-00042M-Nx for qemu-devel@nongnu.org; Sun, 18 Oct 2009 12:57:50 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:51242) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MzZ4n-0005yQ-VS for qemu-devel@nongnu.org; Sun, 18 Oct 2009 12:57:50 -0400 Message-ID: <4ADB48D7.30102@snarc.org> Date: Sun, 18 Oct 2009 17:56:55 +0100 From: Vincent Hanquez MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module References: <1255037747-3340-1-git-send-email-lcapitulino@redhat.com> <1255037747-3340-2-git-send-email-lcapitulino@redhat.com> <4AD72B88.2040107@codemonkey.ws> <20091015122622.1f93ea2d@doriath> <20091015163936.GB532@redhat.com> <20091015142837.6c90580a@doriath> <4AD76B3C.3050001@codemonkey.ws> <4AD87424.3010000@redhat.com> <4AD87901.5030705@codemonkey.ws> <4AD8AECE.9000507@redhat.com> <4AD8AFA4.4070203@codemonkey.ws> <4AD8CB31.9080809@redhat.com> <4AD8E7B5.8000509@codemonkey.ws> <4AD910BA.4090607@gnu.org> <4AD922EB.5030501@codemonkey.ws> <4AD995FD.6070202@snarc.org> <20091018120631.0ab44d80@doriath> <4ADB2EF5.3040108@snarc.org> <20091018133554.43263769@doriath> In-Reply-To: <20091018133554.43263769@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Paolo Bonzini , qemu-devel@nongnu.org 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