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

[Avi Kivity <avi@redhat.com>]

On 06/23/2009 09:32 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>>
>> An RPC makes it a lot easier for clients to parse, there's no need 
>> for a regular expression per command, or to bother with line 
>> continuations etc.  You just focus on the data.
>>
>> We have an opportunity to make a clean break, let's make use of it.
>
> If we structure things internally correctly, by having a flow that 
> basically looks like:
>
> int <monitor_command>(Monitor *mon, <args>)
> {
>   // process args
>   if (success) {
>       monitor_print_data(mon, <highly structured output>);
>    } else {
>       record_extended_error(<message>);
>       return error_code;
>    }
> }
>
> Then it that works well for both the human monitor and the computer 
> monitor.  It's an RPC though.

It looks brittle to me.  What if you want to add an array?  Some 
structure that contains a nested structure?

> Should we support other types of RPCs?  I don't know.  I'd think that 
> you could create a computer monitor -> jsonrpc bridge easily enough.

No doubt, but I look at jsonrpc as a way of reducing the effort in 
qemu.  Not so much interested in it for its own sake.

> If we implement this correctly, then an RPC interface could just be 
> another option to see the computer monitor mode implemented as a 
> "module".

This is deep into overkill territory IMO.  We should pick some format 
that is good enough and has implementations for a variety of languages.  
Luiz' RFC was well done, but the subject is complex enough to be 
difficult to get right.  And as far as I could tell, all the issues are 
addressed by jsonrpc.  The only downside I can see is that jsonrpc is 
some kind of ajax-kiddie web-2.0 script dom thingie while we are a 
serious UNIX style daemon that complies with RFC 123456.


>>> I don't want to invent Xen-API here and go through that pain in QEMU.
>>
>> I don't see the parallel.
>
> Xen-API was the "clean break" for Xend.
>

Anything can be screwed up.  Normally I'm very much against rewrites and 
totally for incremental progress, but when it comes to protocols, you 
have to get them right first shot.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.