Il 03/07/2013 18:06, Anthony Liguori ha scritto:
> Paolo Bonzini <pbonz...@redhat.com> writes:
>
>> Il 03/07/2013 14:54, Anthony Liguori ha scritto:
>>>> So, qapi-schema.json has to be readable/writable _mostly_ by humans.
>>>> That it is valid JSON is little more than a curious accident, because
>>>
>>> I can assure you that it wasn't an accident.
>>
>> Sure, it is not. But when designing the right API for a QMP client, it
>> doesn't matter if it is or not. If QMP used ASN.1 or something like
>> that as the wire protocol, we would not use JSON just for the schema,
>> would we?
>
> JSON is a pretty good representation of Python data structures and the
> intention was for qapi-schema.json to be generated by another tool.
>
> But I understand the point you're trying to make. The thing is, QMP is
> JSON now so it's somewhat academic.
If we generated a Python or C API based on the schema, should the client
care (or know) that QMP is JSON?
>> Does 'type' have argument 'foo':
>>
>> bool('foo' in type_dict['data']) or
>> bool('*foo' in type_dict['data'])
>>
>> (as a QMP client I want to send the argument, I don't care if it is
>> optional or not) and here the abstraction is already falling, IMHO. It
>> should be one of these:
>
> Whether 'type' is in 'foo' is a static property. We would never add
> non-optional arguments to a function so the first part of the clause is
> a constant expression.
What about returned types? I'm not sure we've never added non-optional
arguments, even though in principle it was not the right thing to do.
>>> C) Does 'enum' have 'value'
>>> - bool('value' in enum_dict['data'])
>>>
>>> D) Does 'command' have 'parameter'
>>> - bool('parameter' in command_dict['data'])
>>
>> What is the type of 'parameter' in command:
>>
>> command_dict['data']['parameter'] or
>> command_dict['data']['*parameter']
>
> That's a fair point. But again, this is a constant expression. Type
> values never change.
Not necessarily, a type that is currently used in two places can be
split in two different types, with different optional fields.
I understand though that command_dict['data']['parameter'] is either
always true or always false, because new parameters are always added as
optional. Still, for something that targets a new-enough QEMU only,
there is no need to know if the parameter has always been there, or was
added as optional.
> What are we really optimizing here for?
I think we should optimize for the clients, not for ourselves.
Paolo
> Regards,
>
> Anthony Liguori
>
>> It should be something like these:
>>
>> command_dict['data'].arguments['parameter'].type
>> command_dict['data']['arguments']['parameter']['type']
>>
>>>> The example that Eric sent is not something that I would find easy to
>>>> read/write. qapi-schema.json instead is more than acceptable.
>>>
>>> I don't think the example Eric sent is any easier to parse
>>> programmatically.
>>
>> It is, see the above examples.
>>
>>> That's the problem I have here. I don't see why we
>>> can't have both a human readable and machine readable syntax.
>>
>> It is machine readable, but that doesn't mean it constitutes a nice API.
>>
>> Paolo
>>
>>> Furthermore, qapi.py is an existence proof that we do :-)
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>>
>>>> Paolo
>>>
>
>
>
