From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9nGr-0001CB-IK for qemu-devel@nongnu.org; Mon, 19 Mar 2012 20:49:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9nGp-0003DA-LC for qemu-devel@nongnu.org; Mon, 19 Mar 2012 20:49:53 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:60277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9nGp-0003CU-G4 for qemu-devel@nongnu.org; Mon, 19 Mar 2012 20:49:51 -0400 Received: by obbwd20 with SMTP id wd20so1551996obb.4 for ; Mon, 19 Mar 2012 17:49:49 -0700 (PDT) Message-ID: <4F67D42A.8080400@codemonkey.ws> Date: Mon, 19 Mar 2012 19:49:46 -0500 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: <20120319234559.GB2994@illuin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Michael Roth Cc: Paolo Bonzini , Eric Blake , qemu-devel@nongnu.org, Luiz Capitulino 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. That means we need a way to check if a command has an argument. We could do this as nested lists: if (commands.has_key('query-netdev') and commands['query-netdev']['args'].has_key('interface')): qmp.query_netdev(foo) else: qmp.query_netdev() This is only really possible in a dynamically typed language, which sucks, but let's ignore that for now. This is a bit more complicated but unfortunately, it's not enough. Because we can add members to structures and structures can be arguments. So we really need a way to say: 1) Do we have the query-netdev command 2) Does it take a parameter called interface of type NetDevArgument 3) Does the NetDevArgument have a member called 'foo'. But this actually can be arbitrarily deep in terms of complex. Maybe you make a simple query language so you can execute schema queries in a single line. So you have an interface definition that is the schema that describes an unstructured wire protocol and a query language to determine when and how the schema changes. If that doesn't ring a bell to you, congratulations, you've invented SOAP. The interface description in SOAP is WSDL and XPath is the query language. Writing a SOAP client is a train wreck. It's so bad that even in dynamic languages, people almost always use code generators. A good RPC makes the client simple. If that means we need to take care when introducing new interfaces, then it's a small price to pay for avoiding the nightmares of an over engineered RPC like SOAP. Regards, Anthony Liguori > Thinking about it more the, this does seem to be completely at odds with > any future prospects of a libqmp, so that's a pretty big trade-off... > >> >> Regards, >> >> Anthony Liguori >> >>>> >>> >>