From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJBEg-0000OA-RF for qemu-devel@nongnu.org; Tue, 23 Jun 2009 15:00:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJBEc-0000HB-NX for qemu-devel@nongnu.org; Tue, 23 Jun 2009 15:00:50 -0400 Received: from [199.232.76.173] (port=57524 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJBEc-0000Gz-Ca for qemu-devel@nongnu.org; Tue, 23 Jun 2009 15:00:46 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:52994) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJBEb-0005Bi-Ug for qemu-devel@nongnu.org; Tue, 23 Jun 2009 15:00:46 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5NItwAC025195 for ; Tue, 23 Jun 2009 14:55:58 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5NJ0isj256192 for ; Tue, 23 Jun 2009 15:00:44 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5NJ0i3q022309 for ; Tue, 23 Jun 2009 15:00:44 -0400 Message-ID: <4A412659.1080803@us.ibm.com> Date: Tue, 23 Jun 2009 14:00:41 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file 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> In-Reply-To: <4A412339.5000109@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Vincent Hanquez 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? I can't find one that even has a functioning website. >> If we implement this correctly, then an RPC interface could just be >> another option to see the computer monitor mode implemented as a >> "module". > > This is deep into overkill territory IMO. We should pick some format > that is good enough and has implementations for a variety of > languages. Luiz' RFC was well done, but the subject is complex enough > to be difficult to get right. And as far as I could tell, all the > issues are addressed by jsonrpc. The only downside I can see is that > jsonrpc is some kind of ajax-kiddie web-2.0 script dom thingie while > we are a serious UNIX style daemon that complies with RFC 123456. 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. 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. 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. -- Regards, Anthony Liguori