From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJSDc-0007KT-7N for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:08:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJSDX-0007Ii-IA for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:08:51 -0400 Received: from [199.232.76.173] (port=59304 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJSDX-0007Ia-CM for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:08:47 -0400 Received: from mx2.redhat.com ([66.187.237.31]:51939) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJSDW-0002mo-IW for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:08:47 -0400 Message-ID: <4A422592.2000307@redhat.com> Date: Wed, 24 Jun 2009 16:09:38 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <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> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> In-Reply-To: <4A42200C.6060600@codemonkey.ws> 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: Anthony Liguori Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Vincent Hanquez On 06/24/2009 03:46 PM, Anthony Liguori wrote: > There are two questions to resolve. The first is whether we should > continue with the current direction (line-based protocol) or whether > we should switch to an RPC. The second question is which RPC we > should use. > > I'm not at all convinced that we should switch to an RPC mechanism in > the first place. Perhaps someone could summarize the advantages of > doing this because right now, I don't see many. Less effort for us. Less effort for clients. Less documentation effort. Less likelihood of design and implementation holes (cf. UTF-8, quoting). Richer data types (arrays, structures, nesting). > With respect to RPC choice, if we did go that route, I'd be very > concerned about using jsonrpc verses a more well established rpc. I > would honestly prefer xml-rpc over jsonrpc. I agree xml-rpc is a more rational choice than jsonrpc, but I cannot find it in my heart to say something nice about xml. Additionally, XML parsers are pretty heavy. > One reason to choose an RPC is based on the adoption of it. You want > to use something that has a vibrant community with well established > client libraries to make writing clients as easy as possible. Without > an active jsonrpc C library, it's hard to argue that jsonrpc has > that. xml-rpc certainly does. jsonrpc really is a trivial addition over json, and json is pretty widespread. I think I saw a Python jsonrpc implementation. The important thing however is to reuse, it doesn't really matter what we reuse really as long as it's good enough. -- error compiling committee.c: too many arguments to function