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

[Vincent Hanquez]

On Tue, Jun 23, 2009 at 11:09:21AM -0500, Anthony Liguori wrote:
> Avi Kivity wrote:
>>> I'd rather not do json.
>>>
>>
>> Why not?
>
> Because it's too much complexity at this level in the stack.

It's not.

instead of replying the OK, ERROR .. you reply a JsonRPC OK|ERROR structure
with the same string (quoted and utf-8) as the data payload.

instead of parsing each command line with the text protocol thing, you'll get
every parameter from a json array of string (can contain any characters
compared to QMP so far).

if you want you can make things generic at the marshalling level, by using
string everywhere .. which is what QMP is doing.

>>> As they stand, I think the current patch set is very close to being  
>>> mergable.  I'd rather not go off on a new tangent.
>>
>> It fulfils all are requirements and more.  There's a C implementation  
>> available.  We can concentrate on the commands and ignore the plumbing.
>
> The same is true for XML-RPC, CIM, dbus, etc.  RPC grow like weeds.  In  
> 5 years, it will be shocking that qemu uses jsonrpc instead of the next  
> super-neat RPC protocol.
>
> If we did a real RPC mechanism, I'd want to stick with something  
> tried-and-true like XDR.  But an RPC mechanism is not the monitor.  If  
> we were going to do that, there's no point in morphing the monitor into  
> that.

CIM, dbus are binary protocol. same apparently for XDR (which i've never used).
only XMLRPC is fairly similar (but much more verbose and xml is ugly)

Jsonrpc is just one "standard" marshalling protocol, that I think would fit
quite well, but the point is using something already out there not something
that looks like the evil cousin of the IRC protocol.

Usually too, if the rpc has been correctly bolted on something, changing one to
the other is usually trivial (for example xmlrpc to jsonrpc or the other way).
So maybe in 5 years, people will push for a new protocol XYZ .. but that doesn't
mean it's not going to happen to QMP too anyway...

> What we're doing here is adding a computer-mode to the existing monitor.  
> This will be easy for current apps to consume and for us to transition 
> the code base to.  It's a safe and incremental improvement.

i don't see my "proposal", as going against this statement. you could bolt
jsonrpc or xmlrpc or <insert your known protocol> in an incremental fashion too.

> I don't want to invent Xen-API here and go through that pain in QEMU.

This is really *not* comparable to Xen-API. QEMU manage VM and only VM.
Xen-API goes much further.

-- 
Vincent