From: Paolo Bonzini <pbonzini@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com,
Amos Kong <akong@redhat.com>,
armbru@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP
Date: Wed, 03 Jul 2013 16:45:47 +0200 [thread overview]
Message-ID: <51D4391B.20106@redhat.com> (raw)
In-Reply-To: <87wqp7g5wo.fsf@codemonkey.ws>
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?
> 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:
'foo' in type_dict['data'].fields
'foo' in type_dict['data']['fields']
> 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']
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
>
next prev parent reply other threads:[~2013-07-03 14:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 12:24 [Qemu-devel] [PATCH] full introspection support for QMP Amos Kong
2013-06-19 12:49 ` Amos Kong
2013-06-20 10:16 ` Amos Kong
2013-07-02 16:39 ` Eric Blake
2013-06-21 3:20 ` Luiz Capitulino
2013-07-02 8:37 ` Amos Kong
2013-07-02 14:20 ` Luiz Capitulino
2013-07-16 10:52 ` Amos Kong
2013-07-02 14:51 ` Anthony Liguori
2013-07-02 15:28 ` Eric Blake
2013-07-02 15:39 ` Daniel P. Berrange
2013-07-02 16:44 ` Eric Blake
2013-07-02 17:01 ` Paolo Bonzini
2013-07-02 17:06 ` Eric Blake
2013-07-02 18:27 ` Anthony Liguori
2013-07-04 3:54 ` Amos Kong
2013-07-02 18:21 ` Anthony Liguori
2013-07-02 20:00 ` Paolo Bonzini
2013-07-02 20:08 ` Eric Blake
2013-07-02 20:58 ` Anthony Liguori
2013-07-03 5:52 ` Paolo Bonzini
2013-07-03 12:54 ` Anthony Liguori
2013-07-03 14:45 ` Paolo Bonzini [this message]
2013-07-03 16:06 ` Anthony Liguori
2013-07-04 7:53 ` Paolo Bonzini
2013-07-11 13:37 ` Amos Kong
2013-07-02 17:06 ` Anthony Liguori
2013-07-02 17:11 ` Eric Blake
2013-07-02 18:28 ` Anthony Liguori
2013-07-03 15:08 ` Kevin Wolf
2013-07-03 15:59 ` Anthony Liguori
2013-07-04 7:42 ` Kevin Wolf
2013-07-04 7:55 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51D4391B.20106@redhat.com \
--to=pbonzini@redhat.com \
--cc=akong@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qiaonuohan@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).