From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuPUS-0000Jd-M4 for qemu-devel@nongnu.org; Wed, 03 Jul 2013 12:01:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuPUQ-0002Al-Ky for qemu-devel@nongnu.org; Wed, 03 Jul 2013 12:01:08 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:53918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuPUQ-00029V-Gg for qemu-devel@nongnu.org; Wed, 03 Jul 2013 12:01:06 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Jul 2013 17:01:03 +0100 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id B63E0C9006D for ; Wed, 3 Jul 2013 12:00:58 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r63FxouU61210666 for ; Wed, 3 Jul 2013 11:59:50 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r63Fxnmn019451 for ; Wed, 3 Jul 2013 12:59:50 -0300 From: Anthony Liguori In-Reply-To: <20130703150807.GC2784@dhcp-200-207.str.redhat.com> References: <1371644677-11041-1-git-send-email-akong@redhat.com> <878v1pqak4.fsf@codemonkey.ws> <51D2F1B3.1080903@redhat.com> <87a9m4j3i7.fsf@codemonkey.ws> <20130703150807.GC2784@dhcp-200-207.str.redhat.com> Date: Wed, 03 Jul 2013 10:59:35 -0500 Message-ID: <8761wrk520.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com, pbonzini@redhat.com, Amos Kong Kevin Wolf writes: > Am 02.07.2013 um 19:06 hat Anthony Liguori geschrieben: >> Eric Blake writes: >> > On 07/02/2013 08:51 AM, Anthony Liguori wrote: >> >> Amos Kong writes: >> >> >> >>> Introduces new monitor command to query QMP schema information, >> >>> the return data is a nested dict/list, it contains the useful >> >>> metadata. >> >>> >> >>> we can add events definations to qapi-schema.json, then it can >> >>> also be queried. >> >>> >> >>> Signed-off-by: Amos Kong >> >> >> >> Maybe I'm being too meta here, but why not just return qapi-schema.json >> >> as a string and call it as day? > > I know you don't agree with this, but as I mentioned several times > before, I think the schema as returned by the introspection functions > shouldn't contain what a qemu of this version _could_ in theory provide, > but what this specific build actually _does_ provide. It shouldn't > include things that are compiled out. I really don't disagree with you here. I just don't like having two formats for the schema. >> > I've also been the one arguing that the additional complexity (an array of >> > {"name":"str","type":"str","optional":bool"}) is better for libvirt in >> > that the JSON is then well-suited for scanning (it is easier to scan >> > through an array where the key is a constant "name", and looking for the >> > value that we are interested in, than it is to scan through a dictionary >> > where the keys of the dictionary are the names we are interested in). >> > That is, the JSON in qapi-schema.json is a nice compact representation >> > that works for humans, but may be a bit TOO compact for handling via >> > machines. >> >> But adding a bunch of code to do JSON translation just adds a bunch of >> additional complexity. >> >> One reasonable compromise would be: >> >> { "command": "foo", "arguments": { "name": "str", "id": "int" }, >> "optional": { "bar": "bool" } } > > This assumes that optional vs. mandatory is the only property we ever > want to describe for fields. Eric's approach is much more future-proof. > Let's keep the format of qapi-schema.json an implementation detail that > we can change and extend when necessary. It's always possible to add another argument that describes additional information. For instance: { "command": "foo", "arguments": { "name": "str", "id": "int" }, "optional": { "bar": "bool" }, "defaults": { "bar": false } } That doesn't mean I think exposing defaults is good, but rather that it's still possible to do this in a compact form. Regards, Anthony Liguori > > Kevin