From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJXaP-0001u3-Uh for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:52:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJXaL-0001rK-Dh for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:52:45 -0400 Received: from [199.232.76.173] (port=48516 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJXaL-0001rF-AI for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:52:41 -0400 Received: from mx20.gnu.org ([199.232.41.8]:25592) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJXaK-0006Tb-Eo for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:52:40 -0400 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJXaH-0004bT-7O for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:52:37 -0400 Date: Wed, 24 Jun 2009 19:52:33 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624185233.GO14121@shareable.org> References: <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> <4A422592.2000307@redhat.com> <20090624162207.GD14121@shareable.org> <4A42538A.9000807@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A42538A.9000807@redhat.com> 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: > On 06/24/2009 07:22 PM, Jamie Lokier wrote: > >Avi Kivity wrote: > > > >>>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. > >> > > > >I'm not defending XML here, but: > > > >You can code a minimal XML parser in straight C quite easily, > > One of the points of using an existing RPC implementation is not to have > to code it up. In my experience, using some existing RPC implementations tends to involve quite a lot of code, and implementing from scratch only a little more, when we're talking about *simple* RPC protocols. Like QEMU's monitor for example. You still reuse code of course, but it's things like sockets, buffering, select and dispatch loops. Obviously if it's something larger it's good to start with a good library. One which not only exists, but doesn't need a lot of application boilerplate. RPC libraries vary a lot in how much application code they need you to write. I don't know whether there are good XML-RPC libraries for C. There doesn't seem to be much for JSON-RPC services. > >if it's a restricted subset. > > You can't control what's coming in from the other side. You can reject it if the protocol specification says it's not allowed. Some protocols do that. Otherwise you have to process it correctly. It's trivial to reject byte values that shouldn't be there. -- Jamie