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

[Avi Kivity <avi@redhat.com>]

On 06/23/2009 10:00 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> It looks brittle to me.  What if you want to add an array?  Some 
>> structure that contains a nested structure?
>
> Can you give me concrete examples?

You want statistics for all network interfaces in one go.  In RPC you 
return [ { name: blah stats: { rx: { packets: 123, bytes: 456, errors: 
789 }, tx: etc.  In a text protocol you have more work to write, parse, 
and most importantly document the protocol.

> The typical way this would be handled in an RPC library in C is to 
> introduce complex types.  For instance, you could have a MonitorList 
> and a corresponding MON_LIST type.  FWIW, is there a jsonrpc library 
> for C that's actually maintained?
>
> I can't find one that even has a functioning website.

I think a json C library would be sufficient, there likely are several.  
The RPC part is really trivial for a server.

>> 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.
>
> There are many reasons why JSON is a bad representation.  For 
> starters, there is no way to encode NULL values in a JSON string.  
> This means you cannot send binary data unless you base64 encode it 
> first.  The bounds of integers are also not well defined but most 
> implementations restrict integers to int32.  You basically cannot send 
> 64-bit integers without encoding them first.  It gets really hairy.

These look like show stoppers to me.

> For jsonrpc, there's no standard way to enumerate methods like there 
> is in xml-rpc and jsonrpc isn't self-describing.  Having an RPC be 
> self-describing is really useful when dealing with a dynamic language 
> because you can then avoid IDL compilation.

I think you can avoid IDL compilation even without a self describing RPC.

> So as far as RPCs go, jsonrpc is actually a pretty bad one.  The odd 
> thing about it is you still have to parse json in JavaScript to avoid 
> security problems.  Parsing json in js seems to eliminate 99% of the 
> useness of it.

Are you referring to the fact that eval() on json is insecure?  We don't 
have eval() in C.

Well, if not json, let's find some established RPC (or just data 
serialization) that is not XML-RPC or Sun RPC and use it, so we can 
concentrate on adding commands easily rather than writing formats, 
formatters, and parsers.

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