qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Filip Navara
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Wed, 24 Jun 2009 20:55:52 +0200

On Wed, Jun 24, 2009 at 8:42 PM, Vincent Hanquez<address@hidden> wrote:
> On Wed, Jun 24, 2009 at 08:23:06PM +0200, Filip Navara wrote:
>> On Wed, Jun 24, 2009 at 7:39 PM, Vincent Hanquez<address@hidden> wrote:
>> > On Wed, Jun 24, 2009 at 05:22:07PM +0100, Jamie Lokier wrote:
>> >> You can code a minimal XML parser in straight C quite easily, if it's
>> >> a restricted subset.
>> >
>> > even the restricted subset is not as straighforward as a json parser. and
>> > usually using a subset means you can't interact correctly with the one that
>> > does the full spec.
>> >
>> >> XML and JSON both have the same ugly problem with binary data: they
>> >> can't carry it.  It's usually base64 encoded.  Then again the QEMU
>> >> monitor is no better this respect :-)
>> >
>> > JSon ***DOES*** do binary data.
>> >
>> > C String "abc\0\xff" -> Json String "abc\0000\00ff"
>
> btw, sorry i meant \\ instead of \ in the json string.
> as in: 'a' 'b' 'c' '\\' '0' '0' '0' '0' '\\' '0' '0' 'f' 'f'
>
>> I find the Json representation problematic. In C you have two distinct
>> data types - null-terminated string where the length is implicitly
>> known from the content (char *string) and a binary data blob (char
>> *buffer, int size). If you encode them into the same JSON data type
>> and don't supply "out-of-band" information about which one of the C
>> types is it, the receiver has no way to decide what to decode it into.
>> JSONRPC allows supplying this "out-of-band" information only for the
>> JSON data types which is very limiting.
>
> it's a problem related to the representation of your string, not of JSon.
>
> in most case it doesn't matter though, since if your string contains null 
> that you
> want to send you need to use the correct "json_append_string" in the first
> place which will take the lenght as parameter and on the receiving end you can
> expect that every characters received were meant to be sent and need to use 
> the proper
> accessor to get the string of the proper lenght.
>

*need to use the proper accessor to get the string of the proper length*

This is precisely what I am talking about when I'm talking about
mixing syntax and semantics. You'd require the parser to know the
semantics based on context. That's bad enough of itself, but
fortunately JSONRPC supports "service descriptions" which allow the
parser to be fed with some generic description of the semantics.
Unfortunately this service description doesn't cover all C data types
and can't even describe the basic integer sizes, which would allow for
syntax and semantic validation of the RPC payload by the parser.

Best regards,
Filip Navara




reply via email to

[Prev in Thread] Current Thread [Next in Thread]