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

[Vincent Hanquez]

On Wed, Jun 24, 2009 at 07:46:04AM -0500, Anthony Liguori wrote:
> There are two questions to resolve.  The first is whether we should  
> continue with the current direction (line-based protocol) or whether we  
> should switch to an RPC.  The second question is which RPC we should use.

well, when choosing simple RPC like xmlrpc or jsonrpc you still need to
do the transport. so it could well be a line-based protocol that happens
to contains query in a JSONRPC or XMLRPC format ... as long as you don't
pretty print JSONRPC or XMLRPC (guaranteed to not contain \n). a bit clunky
but possible.

> I'm not at all convinced that we should switch to an RPC mechanism in  
> the first place.  Perhaps someone could summarize the advantages of  
> doing this because right now, I don't see many.
>
> With respect to RPC choice, if we did go that route, I'd be very  
> concerned about using jsonrpc verses a more well established rpc.  I  
> would honestly prefer xml-rpc over jsonrpc.

while i have a profound distaste of xmlrpc ... i still think that would
be a improvement against the current situation .. or even to QMP.

however you have to keep in mind that xmlrpc means no binary data,
and depending on an XML library (compare to beeing able to pull a very tiny
code base directly in qemu tree)

> One reason to choose an RPC is based on the adoption of it.  You want to  
> use something that has a vibrant community with well established client  
> libraries to make writing clients as easy as possible.  Without an  
> active jsonrpc C library, it's hard to argue that jsonrpc has that.   
> xml-rpc certainly does.

it might be missing for C, but lots of language got a maintained and used
library nowadays. We're using it in ocaml, and i have to say we haven't 
been disappointed using it, compared to the number of disappointments with
xmlrpc (and mostly xml in general).

That said, I'll make a C library even if qemu doesn't end up using it.

-- 
Vincent