On Mon, 19 Mar 2012 19:49:46 -0500 Anthony Liguori <anth...@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?
