Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file

[Anthony Liguori <anthony@codemonkey.ws>]

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.

It is relatively easy to parse a line based protocol.  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.

>> This is exactly what happened with Xend's transition from SExpr/HTTP 
>> (custom RPC) -> XML-RPC -> XenAPI.  libvirt still uses SExpr/HTTP 
>> because the cost of switching to the new way of doing things didn't 
>> warrant the return on investment.
>
> I think this points to libvirt doing something wrong.  I suspect it's 
> the implementation language.
>
>> s/libvirt/any other management tool that works today/g
>
> 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.

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.

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.

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.

Regards,

Anthony Liguori