Re: [Qemu-devel] [PATCH] full introspection support for QMP

[Paolo Bonzini <pbonzini@redhat.com>]

Il 03/07/2013 18:06, Anthony Liguori ha scritto:
> Paolo Bonzini <pbonzini@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
>>>
> 
> 
>