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: Vincent Hanquez
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Wed, 24 Jun 2009 19:42:15 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

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.

-- 
Vincent




reply via email to

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