From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MK7UL-0007yd-PU for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:12:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MK7UG-0007uq-WB for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:12:53 -0400 Received: from [199.232.76.173] (port=41575 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MK7UG-0007uc-QS for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:12:48 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43365) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MK7UG-0001nr-BC for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:12:48 -0400 Message-ID: <4A449113.8070907@redhat.com> Date: Fri, 26 Jun 2009 12:12:51 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <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> <5b31733c0906240857g546316e0pd92fee9afe6115fa@mail.gmail.com> <4A4252DD.70300@redhat.com> <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> In-Reply-To: <4A43D600.8060605@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; 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" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Vincent Hanquez On 06/25/2009 10:54 PM, 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. IDL does suck, but dynamic languages generally don't need it. > It is relatively easy to parse a line based protocol. Certainly > easier than most poorly designed RPCs. The idea is that the parsers have already been written. And I doubt that our RPC masquerading as a line based protocol wouldn't earn the "poorly designed" epithet after a few years of cruft have accumulated. In Python, adding a new RPC procedure call amounts to typing in the procedure name and its arguments. It really cannot be any simpler than that. On the other hand QMP calls for a hand written emitter and parser for each command. > 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. Writing a lot of code is worse than crap code someone else writes. > 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. Don't read that C code. I doubt we'll have funky type problems. >> Anything written in a high level language (say, Python) will be >> trivial to port to an RPC. RPC clients in Python can be typed in >> with one finger in a couple of minutes. > > 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. > I've seen this, and while it fell below by expectations, it's something done once rather than per procedure. > 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. With QMP we don't have a standard way to transport anything (the None problem can be avoided by not allowing it at all). > 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. Merging is a meaningless milestone since the protocol will not be enabled. Since we'll miss 0.11 in reality we have 7-8 months before the protocol can be used in production. IMO you're optimizing for the short term, disregarding long-term maintenance, and disregarding ease of implementation for users of the qemu monitor. > I don't believe an RPC is going to be a dramatic simplification. 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. 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. We are not in agreement on jsonrpc (we could easily use a json library and implement the rpc ourselves). Even though I dislike xml-rpc, I'd prefer it to a custom protocol. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.