Paolo Bonzini <pbonz...@redhat.com> writes:
> Il 02/07/2013 22:58, Anthony Liguori ha scritto:
>> > > We consume the schema in QEMU. No reason for us to consume it in a
>> > > different format than libvirt.
>> >
>> > One reason could be that qapi-schema.json, as written, lacks a schema
>> > that can be expressed itself using QAPI.
>>
>> Yup, but how much does that matter in practice?
>
> It matters little because we do not provide a library of QAPI
> parsers/visitors, so clients have to invent their own anyway.
>
> But if we did, clients would be completely oblivious of the fact that
> QMP is based on JSON. Sending qapi-schema.json down the wire as a JSON
> string would break the abstraction that we provide to the clients.
>
>> At any rate, if we wanted to solve this problem--a self-describing
>> schema--we should do it in qapi-schema.json too.
>
> I disagree. I also disagree that qapi-schema.json, as written, is a
> format designed for machine consumption.
>
> 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. 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.
The only reason we don't use json.loads() is because we want to provide
stable ordering for generated command line arguments and struct
members. We can't get that guarantee with the json module.
But this doesn't matter for a client. QMP doesn't have a notion of
argument ordering.
> 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
To answer:
A) Is 'type' valid?
- bool('type' in type_dict)
B) Does 'type' have optional parameter 'foo':
- bool('*foo' in type_dict['data'])
C) Does 'enum' have 'value'
- bool('value' in enum_dict['data'])
D) Does 'command' have 'parameter'
- bool('parameter' in command_dict['data'])
Now we could certainly return dictionaries instead of a list but that's
a trivial post-processing step.
> 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. That's the problem I have here. I don't see why we
can't have both a human readable and machine readable syntax.
Furthermore, qapi.py is an existence proof that we do :-)
Regards,
Anthony Liguori
>
> Paolo
