From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzYvE-0004tf-0c for qemu-devel@nongnu.org; Sun, 18 Oct 2009 12:47:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzYv9-0004iJ-2Q for qemu-devel@nongnu.org; Sun, 18 Oct 2009 12:47:55 -0400 Received: from [199.232.76.173] (port=59261 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzYv8-0004hz-Qr for qemu-devel@nongnu.org; Sun, 18 Oct 2009 12:47:50 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:36927) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MzYv8-0004jW-9g for qemu-devel@nongnu.org; Sun, 18 Oct 2009 12:47:50 -0400 Message-ID: <4ADB467F.50300@snarc.org> Date: Sun, 18 Oct 2009 17:46: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> <4ADB427D.4080409@codemonkey.ws> In-Reply-To: <4ADB427D.4080409@codemonkey.ws> 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: Anthony Liguori Cc: Paolo Bonzini , qemu-devel@nongnu.org, Luiz Capitulino 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