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

[Vincent Hanquez <tab@snarc.org>]

On Tue, Jun 23, 2009 at 02:00:41PM -0500, 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?
>
> 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?
>

this one is mentioned on the website and has been changed recently (may 2009):

http://fara.cs.uni-potsdam.de/~jsg/json_parser/

> 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.

i'm not sure why do you think that, but the JSON string are completly escaped
and there's no restricted value (compared to xml) since everything can be as
a last measure be escaped as decimal \1234 .. in a case of a null \0000

for Int, they don't have any precision (infinite number of
digits), so at the C level they should be represented as string of digits. So
that some library represent the int as a C int, doesn't mean the protocol
enforce that on you.

If that would be a problem and you couldn't change the implementation to do the
right thing, you could represent your 64 bits int as a json string, so that the
implementation on the other side represent it adequately.

but again the protocol can handle any length of integer, and there's no
encoding issue because it's just like a human would write an integer of any
precision (i.e. 123218478219742718)

> 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.

does QMP solve the problem here ?

> 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.

but C is not javascript. it's doesn't have eval, so your argument here is
bogus. also JSon doesn't imply to have any dependancy whatsoever on javascript.

-- 
Vincent