From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzXM7-0005NS-Ge for qemu-devel@nongnu.org; Sun, 18 Oct 2009 11:07:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzXM2-0005GT-1C for qemu-devel@nongnu.org; Sun, 18 Oct 2009 11:07:34 -0400 Received: from [199.232.76.173] (port=54874 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzXM1-0005GB-QN for qemu-devel@nongnu.org; Sun, 18 Oct 2009 11:07:29 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:44954) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MzXM1-0005Dh-8V for qemu-devel@nongnu.org; Sun, 18 Oct 2009 11:07:29 -0400 Message-ID: <4ADB2EF5.3040108@snarc.org> Date: Sun, 18 Oct 2009 16:06:29 +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> In-Reply-To: <20091018120631.0ab44d80@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: >> 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". 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). -- Vincent