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

[Jan Kiszka]

Avi Kivity wrote:
> On 05/17/2010 10:57 AM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>    
>>> On 05/17/2010 10:40 AM, Jan Kiszka wrote:
>>>      
>>>>> 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.
>>>>
>>>>        
>>> What is the receiver to do with it?
>>>
>>> If it doesn't know the schema (and there is no schema), then all it can
>>> do is display the key/values.  If it does know the schema, then
>>> __class__ is unnecessary.
>>>      
>> There is a schema describing the fields (name, size, number of
>> elements),
> 
> Surely the schema has to describe the type as well?  If it does, you can 
> use the schema to generate a classes at compile time.
> 
>>   but their types (int, buffer, sub-field, array of X) are
>> derived from the JSON objects (ie. the JSON parser does this job).
>>    
> 
> The names of fields are also type information.

Not in the case of device_show. The clients have no idea of the vmstate
structures before they were transfered. Granted, that will likely remain
a special case in the QMP command set.

> 
>>>> I really don't see the problem with __class__. Being a text protocol,
>>>> JSON is already fairly verbose.
>>>>
>>>>        
>>> The problem is not the verbosity, it's that information is carried too
>>> late.  Many clients want to know this information at compile time or
>>> initialization time, and we are providing it at object instantiating time.
>>>      
>> What clients do you have in mind?
>>
>>    
> 
> Any client that doesn't allow object types to be created dynamically; C, 
> C++, Java, and the like could all benefit from a schema and wouldn't be 
> able to do much with __class__ unless all classes were predefined.  
> Python, JavaScript, and the like wouldn't care.
> 
> Another way of looking at it: if the client sees { __class__: foo, f1: 
> 10, f2: 9 }, it cannot derive any information from __class__ unless it 
> was aware of foo beforehand.  If that's the case, let's make it part of 
> the schema so it is available at compile time instead of runtime.
> 

Maybe a misunderstanding on my side: I'm not arguing against predefining
what __class__ values exists and how dicts that carry such keys are encoded.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux