Re: [Qemu-devel] [RFC/RFA PATCH] qapi: detect extra members inside structs

[Luiz Capitulino <lcapitulino@redhat.com>]

On Mon, 19 Mar 2012 19:49:46 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 03/19/2012 06:45 PM, Michael Roth wrote:
> >>> So IMO, returning arguments actually seems easier for both clients and the
> >>> server, and is more resilient to downstream changes. It does require a more
> >>> formal specification of the protocol though. Basically: "an option/field
> >>> may not be supported in older/future versions of QEMU, so it is up to
> >>> the client to check in advance by referencing the QAPI schema for their
> >>> qemu version or programatically via get_schema(<command>)"
> >>
> >> The complexity of writing a client using get_schema() is close to staggering :-/
> >
> > I'm not sure, I mean, take libvirt, you need to marshall up the
> > arguments anyway and put them into a QMP payload, so in that case the
> > client developer is aware of the schema that they're coding against,
> > and also understand the QAPI schema specification, and if the schema
> > is nested then so is the client version of that "schema".
> >
> > So, conceptually at least, it seems like it wouldn't be that big a jump
> > to maintain an internal representation of their schema to
> > programatically check against the specification they were coding
> > against, it's just the part where they then need to bake it into the
> > client implementation that's a bit heavy-handed.
> 
> So let's work through a few examples.   Today, you have to maintain a list of 
> commands returned from query-commands and check for set membership:
> 
> if 'query-netdev2' in commands:
>     qmp.query_netdev2(foo)
> else:
>     qmp.query_netdev()
> 
> Pretty simple.  If we have a schema representation, we'll need to be able to 
> check for arguments.

Aren't we going to have the schema representation anyway? Or if we go for the
way above we are not going to have it?