qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/8] Add QBuffer


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 3/8] Add QBuffer
Date: Mon, 17 May 2010 09:48:45 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

On 05/17/2010 03:12 AM, Anthony Liguori wrote:
On Sun, May 16, 2010 at 12:38 PM, Jamie Lokier<address@hidden>  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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]