From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZlA6-0005Ie-D4 for qemu-devel@nongnu.org; Tue, 26 Jan 2010 08:08:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZlA1-0005El-Cn for qemu-devel@nongnu.org; Tue, 26 Jan 2010 08:08:53 -0500 Received: from [199.232.76.173] (port=51366 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZlA1-0005EP-4A for qemu-devel@nongnu.org; Tue, 26 Jan 2010 08:08:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11747) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZlA0-0007a9-7K for qemu-devel@nongnu.org; Tue, 26 Jan 2010 08:08:48 -0500 Date: Tue, 26 Jan 2010 13:08:25 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Re: [PATCH] win32: use PRId64 instead of %lld Message-ID: <20100126130825.GH5366@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> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Markus Armbruster , Luiz Capitulino , Herve Poussineau , qemu-devel@nongnu.org, "Michael S. Tsirkin" 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? > > For instance, at some point in time, we're going to do have to do > something about floating point representation. We have the ability to > negotiate these capabilities at run-time. Even if we can negotiate extensions at the protocol level, we need to be careful about how we actually use them. The client is likely going to be using whatever standard JSON client comes with their language/environment and will not neccessarily have ability to change that to make use of the QEMU specific extension. We don't want to end up with QEMU having a nice JSON extension for some core feature, but none of the clients being able to use it in practice. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|