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

[Avi Kivity <avi@redhat.com>]

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