From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJE8Z-00073V-PQ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 18:06:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJE8V-00072M-1U for qemu-devel@nongnu.org; Tue, 23 Jun 2009 18:06:43 -0400 Received: from [199.232.76.173] (port=53057 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJE8U-00072J-V0 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 18:06:38 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:53528) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJE8U-0005QU-Am for qemu-devel@nongnu.org; Tue, 23 Jun 2009 18:06:38 -0400 Date: Tue, 23 Jun 2009 23:02:04 +0100 From: Vincent Hanquez Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090623220204.GA5612@snarc.org> References: <20090623012811.53a62493@doriath> <20090623144521.GA614@snarc.org> <4A40FB11.8090100@redhat.com> <4A40FB26.2040702@us.ibm.com> <4A40FD1A.1040303@redhat.com> <4A40FE31.2010007@us.ibm.com> <4A40FFB0.2070905@redhat.com> <4A411FC5.7050701@us.ibm.com> <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A412659.1080803@us.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity On Tue, Jun 23, 2009 at 02:00:41PM -0500, Anthony Liguori wrote: > Avi Kivity wrote: >> It looks brittle to me. What if you want to add an array? Some >> structure that contains a nested structure? > > Can you give me concrete examples? > > The typical way this would be handled in an RPC library in C is to > introduce complex types. For instance, you could have a MonitorList and > a corresponding MON_LIST type. FWIW, is there a jsonrpc library for C > that's actually maintained? > this one is mentioned on the website and has been changed recently (may 2009): http://fara.cs.uni-potsdam.de/~jsg/json_parser/ > There are many reasons why JSON is a bad representation. For starters, > there is no way to encode NULL values in a JSON string. This means you > cannot send binary data unless you base64 encode it first. The bounds > of integers are also not well defined but most implementations restrict > integers to int32. You basically cannot send 64-bit integers without > encoding them first. It gets really hairy. i'm not sure why do you think that, but the JSON string are completly escaped and there's no restricted value (compared to xml) since everything can be as a last measure be escaped as decimal \1234 .. in a case of a null \0000 for Int, they don't have any precision (infinite number of digits), so at the C level they should be represented as string of digits. So that some library represent the int as a C int, doesn't mean the protocol enforce that on you. If that would be a problem and you couldn't change the implementation to do the right thing, you could represent your 64 bits int as a json string, so that the implementation on the other side represent it adequately. but again the protocol can handle any length of integer, and there's no encoding issue because it's just like a human would write an integer of any precision (i.e. 123218478219742718) > For jsonrpc, there's no standard way to enumerate methods like there is > in xml-rpc and jsonrpc isn't self-describing. Having an RPC be > self-describing is really useful when dealing with a dynamic language > because you can then avoid IDL compilation. does QMP solve the problem here ? > So as far as RPCs go, jsonrpc is actually a pretty bad one. The odd > thing about it is you still have to parse json in JavaScript to avoid > security problems. Parsing json in js seems to eliminate 99% of the > useness of it. but C is not javascript. it's doesn't have eval, so your argument here is bogus. also JSon doesn't imply to have any dependancy whatsoever on javascript. -- Vincent