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