Jan Kiszka <jan.kis...@siemens.com> writes: > 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.
Doesn't that tie you to a specific version of QMP 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. qdev device properties are similar. Right now, they occur only as arguments of device_add. When do_info_qtree() gets converted, they'll appear in results. [...]