From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59530) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOXXa-0004Yf-30 for qemu-devel@nongnu.org; Mon, 23 May 2011 11:59:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOXXY-0007mG-VB for qemu-devel@nongnu.org; Mon, 23 May 2011 11:59:34 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:47280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOXXY-0007mB-Sx for qemu-devel@nongnu.org; Mon, 23 May 2011 11:59:32 -0400 Received: by yxk8 with SMTP id 8so2536880yxk.4 for ; Mon, 23 May 2011 08:59:31 -0700 (PDT) Message-ID: <4DDA8461.2040704@codemonkey.ws> Date: Mon, 23 May 2011 10:59:29 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110520180331.GA21837@amd.home.annexia.org> <4DD6AEB9.6060506@codemonkey.ws> <20110523130411.GR24143@redhat.com> <4DDA620F.1090308@codemonkey.ws> <20110523134021.GT24143@redhat.com> <4DDA663F.30907@codemonkey.ws> <4DDA7829.5090103@codemonkey.ws> <20110523151948.GJ27503@amd.home.annexia.org> <4DDA7C17.6020208@codemonkey.ws> <20110523152944.GK27503@amd.home.annexia.org> In-Reply-To: <20110523152944.GK27503@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Luiz Capitulino , qemu-devel@nongnu.org, Markus Armbruster On 05/23/2011 10:29 AM, Richard W.M. Jones wrote: > On Mon, May 23, 2011 at 10:24:07AM -0500, Anthony Liguori wrote: >> On 05/23/2011 10:19 AM, Richard W.M. Jones wrote: >> What I suggested would let us work with any JSON client, but if >> clients loose precision after 53-bits, those clients would not work >> well with QEMU. > > I totally agree that the JSON "standard" is completely underspecified > and not very useful (lacking a schema, strong typing, well-specified > limits). Nevertheless, for better or worse it's what we're using. > > There is one very important JSON client we are using called libvirt. No, libvirt is a virtualization library. It happens to have a home grown JSON client but down the road, if there's a nice, common JSON library and it decides to switch to it, we don't want to have a bunch of compatibility issues that prevents that from happening. The point of using a standard RPC is to support multiple clients. Otherwise, we should just stop calling it JSON and make it behave the way we want it to. >> The alternative approach is to be conservative and only use 32-bit >> integers and represent everything in two numbers. > > Or use strings ... JSON types are variant. We could send integers great than 53-bits back as strings.. This would break libvirt badly though. > > Rich. >