Il 15/06/2012 19:50, Eric Blake ha scritto:
>> > { 'type': 'BlockJobInfo',
>> > 'data': {'type': 'str', 'device': 'str', 'len': 'int',
>> > - 'offset': 'int', 'paused': 'bool', 'speed': 'int'} }
>> > + 'offset': 'int', 'paused': 'bool', 'speed': 'int',
>> > + 'io-status': 'BlockDeviceIoStatus'} }
> Again, when adding members to output-only types compared to a previous
> release, should we be marking the additions as optional, as in:
>
> '*io-status': 'BlockDeviceIoStatus'
>
> to indicate that the member may not be present when talking to older qemu?
I don't think so, but still we should add it to the documentation.
If in the future we will generate code that exports the types, these
should not be indicated as optional IMHO. Optional is more like a JSON
null value (in fact in Javascript a['nonexistent'] is null). Instead,
we should add a new notation indicating that this could have a default
value (false in the case of 'paused', 'ok' here), and the generated code
would synthesize the default value if the JSON lacks the item.
This could be used also in some commands. We mark some arguments as
optional, but it would be easier to present them as having a default
value. In particular, in a C API likely you would prefer to map such
cases to one C arguments rather than a pair "has_foo"+"foo".
Paolo
