From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MK9l5-0007cg-Js for qemu-devel@nongnu.org; Fri, 26 Jun 2009 07:38:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MK9ky-0007YG-KZ for qemu-devel@nongnu.org; Fri, 26 Jun 2009 07:38:16 -0400 Received: from [199.232.76.173] (port=50314 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MK9ky-0007Y0-48 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 07:38:12 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:37533) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MK9kx-0007pA-JZ for qemu-devel@nongnu.org; Fri, 26 Jun 2009 07:38:11 -0400 Date: Fri, 26 Jun 2009 12:36:05 +0100 From: Vincent Hanquez Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090626113605.GA28595@snarc.org> References: <20090624190539.GR14121@shareable.org> <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> <20090624211358.GA14121@shareable.org> <4A43768A.2090604@eu.citrix.com> <4A438FDD.5060206@redhat.com> <4A43935D.6000506@codemonkey.ws> <4A4395B8.4010401@redhat.com> <4A43BD5D.80307@codemonkey.ws> <4A43C264.6060803@redhat.com> <4A43D600.8060605@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A43D600.8060605@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" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Avi Kivity On Thu, Jun 25, 2009 at 02:54:40PM -0500, Anthony Liguori wrote: > Avi Kivity wrote: >> Adopting an RPC should be easier than adopting QMP, since all you have >> to do is compile the IDL. Again I point to the incremental cost of >> adding a command. > > Having written clients for XML-RPC, SExpr/HTTP, and the QEMU monitor, in > both C and in Python, along with having spent way too much time with > various IDL compilers, I really don't agree with you here. did you write any ad-hoc text base protocol then ? > It is relatively easy to parse a line based protocol. it's not that hard indeed, but now what's the cost of having to replicate this ad-hoc protocol in the management layer that use different languages ? what about the cost of extensibility in the future (hello IMAP) ? > Certainly easier > than most poorly designed RPCs. For RPCs that are not self-described, > you need an IDL compiler to make any sense out of the packets. IDL > compilers are a huge problem because you need to build the compiler and > run it on the same platform unless you choose from the handful of common > compilers. Those compilers/RPCs tend to produce absolutely terrible C > code so you need to do all sorts of tricks to avoid excessive warnings. > For self-describing RPCs (like XML-RPC), you can avoid IDL which is > good. You still end up with pretty funky C code though and the type > system almost always comes back to haunt you. you can avoid IDL in all case, if you choose. it requires more boilerplate in C obviously, but looking at QMP .. it's adding exactly the same boilerplate. > Reality is less rosy. Take a look at Xend's XML-RPC server/client. > Python doesn't provide anything but the most dumb transports. > Implementing custom transports requires poking internal bits of the > class library. It gets ugly really quickly. but it's not the fault of xmlrpc, it's the implementation fault. there's other language out there that got a perfectly fine xmlrpc library, that doesn't assume anything about the transport. worst come to worst, reimplementing XMLRPC is *easy* as long as the marshaling protocol library (XML) is available in a good quality, which is certainly the case in python. The same hold true of JSonRPC, absolutely trivial to implement as long as you got the underlying JSon library. > Also, typing really hurts with dynamic languages because the type > semantics never match up well which causes unexpected failures. A > classic example with XML-RPC is None. There is no standard way to > transport None in XML-RPC although there are common extensions to > support it. Of course, not all clients support it and there isn't > really a standard way to negotiate it. It's really a mess. how does QMP handle None then ? > At this point, we have a close-to-mergable set of patches that provide > real value. I don't see a reason not to merge them once they've been > resubmitted. it provides no real value at this point. it start providing real value when everything out (libvirt, xend, ..) there is using it. script people won't be able to use QMP anyway, and probably still going to use the monitor as it is (you don't expect them to parse a line protocol with quoted string in bash do you ?) > I don't believe an RPC is going to be a dramatic simplification. it's not really a simplification, but QMP while it look simple now (just looking at the C side, without factoring the cost of reimplementing this text protocol in language that want to use it), it's becoming not simple. already the protocol is growing quoted string, utf8 support, ... What's next ? multi line protocol to extends it ? IMAP grew probably the same way, as a simple protocol in the beggining, but look at the very useful description that Felip made (Thanks Felip btw) it's like printing XML yourself with printf instead of using the outputing code of the library because it's "harder". you end up with some not correctly escaped XML, etc > It > could be if there were a high quality RPC out there that had well > maintained client/server libraries. I don't believe such a thing exists > though. If you want to keep arguing this, let's focus on actual RPC > implementations. I think we've agreed that JSON-RPC isn't going to work > because of the lack of client/server library availability. So at this point your dismissing JSON-RPC just on the fact that there's no server/client implementation available right away, but you don't dismiss it on any other ground related to the protocol itself ? is that right ? > XML-RPC > falls into the same boat for C as far as I'm concerned. If there are > any other ones you want to consider, let's look at them so that we can > make progress in this discussion. -- Vincent