From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZl61-0002fD-Ai for qemu-devel@nongnu.org; Tue, 26 Jan 2010 08:04:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZl5v-0002bw-JJ for qemu-devel@nongnu.org; Tue, 26 Jan 2010 08:04:39 -0500 Received: from [199.232.76.173] (port=40706 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZl5u-0002bn-T3 for qemu-devel@nongnu.org; Tue, 26 Jan 2010 08:04:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30114) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZl5u-0006p7-1R for qemu-devel@nongnu.org; Tue, 26 Jan 2010 08:04:34 -0500 Date: Tue, 26 Jan 2010 15:01:16 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH] win32: use PRId64 instead of %lld Message-ID: <20100126130116.GE19036@redhat.com> References: <1264368221-3040-1-git-send-email-hpoussin@reactos.org> <20100125100905.GA9019@redhat.com> <20100125120348.461ce622@doriath> <20100125132719.23a483cf@doriath> <20100125153838.GB11161@redhat.com> <20100126094329.70719b6f@doriath> <4B5EE450.9090004@linux.vnet.ibm.com> <20100126124642.GB19036@redhat.com> <4B5EE6F8.7040502@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5EE6F8.7040502@linux.vnet.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Herve Poussineau , Markus Armbruster , Luiz Capitulino On Tue, Jan 26, 2010 at 06:58:32AM -0600, Anthony Liguori wrote: > On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote: >> Yes, I agree we are comnpliant. >> But I also think we should be strict and reject non-JSON >> input just so that clients do not come to depend on it. >> > > If we can make JSON better while preserving compatibility and adhering > to the spec, why wouldn't we? Adding '' seems very little gain. The pain point wouild be supporting multiple syntax variants, and inability to use external tools to parse such traffic. > For instance, at some point in time, we're going to do have to do > something about floating point representation. What's the issue? There's '.' and there's 'e' ... And maybe we won't need floating point ever ... > We have the ability to negotiate these capabilities at run-time. > > Regards, > > Anthony Liguori If there's an important capability this might make sense. -- MST