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

[Anthony Liguori <aliguori@us.ibm.com>]

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.

>> The plan had been to start
>> with what the output of a "human friendly" parser would be and then
>> eventually introduce a more IDL like syntax.
>> 
>> qapi-schema.json is valid JSON.  It's a stream of objects.  It's a
>> stream of objects instead of a list to favor readability but that's
>> really the only compromise.
>
> So far so good.
>
>>> overall the syntax greatly favors humans rather than computers.  A
>>> format designed for computers would have a schema such that no parsing
>>> tasks (however small---I'm thinking of the "list of" and "optional"
>>> syntaxes) would be left after parsing the JSON.
>> 
>> Here is how I would handle "processing" qapi-schema.json:
>> 
>> 1) Put all types, unions, and enums in their own dictionary
>> 2) Put commands in a dictionary
>
> Agreed.
>
>> To answer:
>> 
>> A) Is 'type' valid?
>>    - bool('type' in type_dict)
>> 
>> B) Does 'type' have optional parameter 'foo':
>>    - bool('*foo' in type_dict['data'])
>
> 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.

>   'foo' in type_dict['data'].fields
>   'foo' in type_dict['data']['fields']

Not sure I see why the extra layer of indirection is needed.

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

What are we really optimizing here for?  What are the things that
someone is expected to use the schema to do in real life?

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