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

[Vincent Hanquez]

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