From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N4XqP-00007j-AM for qemu-devel@nongnu.org; Sun, 01 Nov 2009 05:39:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N4XqF-000060-8e for qemu-devel@nongnu.org; Sun, 01 Nov 2009 05:39:29 -0500 Received: from [199.232.76.173] (port=44305 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4XqE-00005i-MJ for qemu-devel@nongnu.org; Sun, 01 Nov 2009 05:39:23 -0500 Received: from cerberus.snarc.org ([212.85.155.21]:46256) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N4XqE-0006GH-9R for qemu-devel@nongnu.org; Sun, 01 Nov 2009 05:39:22 -0500 Date: Sun, 1 Nov 2009 12:28:47 +0000 From: Vincent Hanquez Subject: Re: [Qemu-devel] Re: [RFC 0/7] QError v1 Message-ID: <20091101122846.GA14687@snarc.org> References: <1256841750-15228-1-git-send-email-lcapitulino@redhat.com> <4AEA133A.8010906@redhat.com> <20091030102809.1c520282@doriath> <4AEAE261.5030908@redhat.com> <4AEAE56E.8040309@us.ibm.com> <20091030162849.GH3579@shareable.org> <20091030171514.GI21617@redhat.com> <4AEB235B.5000104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AEB235B.5000104@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , qemu-devel@nongnu.org, Luiz Capitulino , Gerd Hoffmann , hollisb@linux.vnet.ibm.com On Fri, Oct 30, 2009 at 06:33:15PM +0100, Paolo Bonzini wrote: > On 10/30/2009 06:15 PM, Daniel P. Berrange wrote: >> If we're going to use JSON we should be 100% compliant with the JSON >> spec, not extend it. By adding custom QEMU extensions, we loose the >> ability for programming language to trivially talk to QEMU using a >> standard JSON parser, and instead everyone has to write custom client >> side code yet again. > > The single-quoted-string extension is just to be used internally to ease > writing JSON templates in C. All emitted text will go through the JSON > encoder, which will be conservative (no extensions) for the reasons you > mention. Are you going to have a mechanism to turn off the extension when the parser is parsing from external source then ? because otherwise it means that qemu is accepting a superset of JSON; so how long before client start by mistake doing the same thing instead of using conformant JSON ? I really can't imagine where typing \"..\" instead of '..' for a couple of strings (10, 30 at most ?) make this single quote string a necessity. -- Vincent