From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJXTy-0003TJ-Be for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:46:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJXTt-0003MF-HK for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:46:05 -0400 Received: from [199.232.76.173] (port=44252 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJXTt-0003Lt-9c for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:46:01 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:43272) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJXTs-0003br-9R for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:46:00 -0400 Date: Wed, 24 Jun 2009 19:42:15 +0100 From: Vincent Hanquez Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624184215.GA17394@snarc.org> References: <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> <4A422592.2000307@redhat.com> <20090624162207.GD14121@shareable.org> <20090624173915.GA16973@snarc.org> <5b31733c0906241123w14dde78dk670ff8f5f83f4c97@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5b31733c0906241123w14dde78dk670ff8f5f83f4c97@mail.gmail.com> Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Navara Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity On Wed, Jun 24, 2009 at 08:23:06PM +0200, Filip Navara wrote: > On Wed, Jun 24, 2009 at 7:39 PM, Vincent Hanquez 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 on= e that > > does the full spec. > > > >> XML and JSON both have the same ugly problem with binary data: they > >> can't carry it. =A0It's usually base64 encoded. =A0Then again the QE= MU > >> 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 firs= t place which will take the lenght as parameter and on the receiving end yo= u can expect that every characters received were meant to be sent and need to u= se the proper accessor to get the string of the proper lenght. --=20 Vincent