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

[Amos Kong <akong@redhat.com>]

On Wed, Jul 03, 2013 at 07:54:47AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <pbonzini@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.