From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJX7q-0002i4-Kw for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:23:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJX7l-0002ZB-Pi for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:23:14 -0400 Received: from [199.232.76.173] (port=40074 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJX7l-0002Yv-C3 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:23:09 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:61542) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJX7k-0005KV-Lk for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:23:08 -0400 Received: by ewy7 with SMTP id 7so1358825ewy.34 for ; Wed, 24 Jun 2009 11:23:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090624173915.GA16973@snarc.org> References: <4A40FFB0.2070905@redhat.com> <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> Date: Wed, 24 Jun 2009 20:23:06 +0200 Message-ID: <5b31733c0906241123w14dde78dk670ff8f5f83f4c97@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 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 th= at > 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 QEMU >> monitor is no better this respect :-) > > JSon ***DOES*** do binary data. > > C String "abc\0\xff" -> Json String "abc\0000\00ff" 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. For text based protocols it's vital to separate the syntax from semantics and decoding the above would require knowning the specific context and semantics. A more natural representation of binary blob in JSON would be array of numbers, but that would have a big overhead. Best regards, Filip Navara