From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9xz3-0007Se-9V for qemu-devel@nongnu.org; Tue, 20 Mar 2012 08:16:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9xyf-00039B-AK for qemu-devel@nongnu.org; Tue, 20 Mar 2012 08:16:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9xyf-00038j-2G for qemu-devel@nongnu.org; Tue, 20 Mar 2012 08:15:49 -0400 Date: Tue, 20 Mar 2012 09:15:50 -0300 From: Luiz Capitulino Message-ID: <20120320091550.35959dc5@doriath.home> In-Reply-To: <4F67D42A.8080400@codemonkey.ws> References: <1332185368-18708-1-git-send-email-pbonzini@redhat.com> <4F678A37.1020101@codemonkey.ws> <4F678E38.7050902@redhat.com> <4F678F6A.3050804@codemonkey.ws> <4F679576.60900@redhat.com> <4F679762.6000201@codemonkey.ws> <20120319174314.74720a38@doriath.home> <20120319222907.GA2994@illuin> <4F67B57E.5040802@codemonkey.ws> <20120319234559.GB2994@illuin> <4F67D42A.8080400@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC/RFA PATCH] qapi: detect extra members inside structs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , Eric Blake , Michael Roth , qemu-devel@nongnu.org On Mon, 19 Mar 2012 19:49:46 -0500 Anthony Liguori 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()" > >> > >> 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?