On Wed, Jul 03, 2013 at 07:54:47AM -0500, Anthony Liguori wrote:
> 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
We need to parse the json strings in qapi-schema.json, and
generate a dynamical & nested dictionary. When qmp clients
get the dictionary, they have to parse the dictionary's values
layer by layer. If we provide the meta-data, it will be easier.
meta-data:
the type of dictionary's value (dictionary, list, string)
if it's optional
Eric, can you give some input? If Anthony's suggestion satisfies
your request?
However, I will send my latest version out latter. let's discuss
on it.
> 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
--
Amos.
