[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP
Date: Thu, 04 Jul 2013 09:53:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

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


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]