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

[Avi Kivity]

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.