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

[Avi Kivity]

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.


> > > 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.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.