From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJXdd-0003fT-QC for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:56:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJXdZ-0003d9-Sd for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:56:05 -0400 Received: from [199.232.76.173] (port=48637 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJXdZ-0003d2-J1 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:56:01 -0400 Received: from mx20.gnu.org ([199.232.41.8]:25846) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJXdY-00086Y-VK for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:56:01 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJXdY-0004sj-5m for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:56:00 -0400 Received: by ewy7 with SMTP id 7so1387348ewy.34 for ; Wed, 24 Jun 2009 11:55:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090624184215.GA17394@snarc.org> References: <4A412339.5000109@redhat.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> <20090624184215.GA17394@snarc.org> Date: Wed, 24 Jun 2009 20:55:52 +0200 Message-ID: <5b31733c0906241155x10d88ce3we814835780bab7c@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file From: Filip Navara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vincent Hanquez 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 8:42 PM, Vincent Hanquez 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 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. =A0It's usually base64 encoded. =A0Then again the QEM= U >> >> 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. > *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