From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50094 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ODuwW-0004kp-88 for qemu-devel@nongnu.org; Mon, 17 May 2010 03:40:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ODuwU-0007xA-Ch for qemu-devel@nongnu.org; Mon, 17 May 2010 03:40:52 -0400 Received: from thoth.sbs.de ([192.35.17.2]:24952) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ODuwU-0007wu-1X for qemu-devel@nongnu.org; Mon, 17 May 2010 03:40:50 -0400 Message-ID: <4BF0F2FD.90408@siemens.com> Date: Mon, 17 May 2010 09:40:45 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <6e14cbfe3764b46d9bd6d2db61d41fd9c85dd54e.1273843151.git.jan.kiszka@siemens.com> <4BED9358.1000106@codemonkey.ws> <20100516173809.GA29814@shareable.org> <4BF0E6CD.7090909@redhat.com> In-Reply-To: <4BF0E6CD.7090909@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Juan Quintela , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino Avi Kivity wrote: > On 05/17/2010 03:12 AM, Anthony Liguori wrote: >> On Sun, May 16, 2010 at 12:38 PM, Jamie Lokier >> wrote: >> >>> Anthony Liguori wrote: >>> >>>> Instead of encoding just as a string, it would be a good idea to encode >>>> it as something like: >>>> >>>> {'__class__': 'base64', 'data': ...} >>>> >>> Is there a benefit to the class indirection, over simply a keyword?: >>> >>> {'__base64__': ...} >>> >>> __class__ seems to suggest much more than it's being used for here. >>> >> Yes. The problem with JSON is that it's based on JavaScript and >> JavaScript is goofy :-) >> >> > > I suggest completely ignoring JavaScript. JSON is simply an encoding > for numbers, strings, arrays, and key-value stores. Where's the goofiness? > >> JavaScript's object mechanism doesn't map well to most other languages >> since it's prototype based. What we're calling QDict's are really >> objects in JavaScript and they carry mostly no type information. With >> JS, it's very simple to treat a generic object as a specialized class >> after instantiation which means objects don't need type information. >> >> For non-prototype languages, which is the vast majority of clients, >> it's necessary to have type information at instantiation time since >> monkey patching is awkward at best. That's why we need a special, >> reserved, object member to carry type information. The remainder of >> the object members represent the serialized state of the object. >> > > The alternative is to have a schema. Sun RPC/XDR doesn't carry any type > information (you can't even distinguish between a number and text) yet C > clients have to problem extracting typed information from it. > > Having __class__ everywhere means we're carrying the schema in every > message instead of just once. The device_show command is already an example where you don't have a predefined schema. It is derived from the data stream the encodes the vmstate fields. So far we have no collision between base64-encoded buffers and real strings, but this may actually change when we start annotating the fields with symbolic constants. I really don't see the problem with __class__. Being a text protocol, JSON is already fairly verbose. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux