From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44197 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ODu8S-00007y-1F for qemu-devel@nongnu.org; Mon, 17 May 2010 02:49:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ODu8I-0000ON-PM for qemu-devel@nongnu.org; Mon, 17 May 2010 02:49:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3043) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ODu8I-0000NK-Aw for qemu-devel@nongnu.org; Mon, 17 May 2010 02:48:58 -0400 Message-ID: <4BF0E6CD.7090909@redhat.com> Date: Mon, 17 May 2010 09:48:45 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/8] Add QBuffer References: <6e14cbfe3764b46d9bd6d2db61d41fd9c85dd54e.1273843151.git.jan.kiszka@siemens.com> <4BED9358.1000106@codemonkey.ws> <20100516173809.GA29814@shareable.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , Juan Quintela , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino 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. > Another way to think of it, is that we're already transmitting objects > so we really just need a way to say, no, this isn't just a Dictionary, > it's really an instance of the following class. > Are there cases where the receiver cannot infer this from the context? As I see it, dynamic type information is easiest for dynamicically typed languages. You just have a dict of class names -> object constructor and call the constructors at runtime. Statically typed languages will need a schema to use objects, since the field types have to be known at compile time, not just run time. Another wart is arrays: statically typed languages usually contain only objects of the same type, but here this isn't known until we process the first member. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.