From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJTB0-0003iL-AZ for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:10:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJTAv-0003d8-DN for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:10:13 -0400 Received: from [199.232.76.173] (port=54400 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJTAv-0003ct-2o for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:10:09 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:52929) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJTAu-00079R-HU for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:10:08 -0400 Date: Wed, 24 Jun 2009 15:06:13 +0100 From: Vincent Hanquez Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624140613.GA15397@snarc.org> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A42200C.6060600@codemonkey.ws> 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 Wed, Jun 24, 2009 at 07:46:04AM -0500, 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. well, when choosing simple RPC like xmlrpc or jsonrpc you still need to do the transport. so it could well be a line-based protocol that happens to contains query in a JSONRPC or XMLRPC format ... as long as you don't pretty print JSONRPC or XMLRPC (guaranteed to not contain \n). a bit clunky but possible. > 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. > > 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. while i have a profound distaste of xmlrpc ... i still think that would be a improvement against the current situation .. or even to QMP. however you have to keep in mind that xmlrpc means no binary data, and depending on an XML library (compare to beeing able to pull a very tiny code base directly in qemu tree) > 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. it might be missing for C, but lots of language got a maintained and used library nowadays. We're using it in ocaml, and i have to say we haven't been disappointed using it, compared to the number of disappointments with xmlrpc (and mostly xml in general). That said, I'll make a C library even if qemu doesn't end up using it. -- Vincent