From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu3gl-0002ZS-Vk for qemu-devel@nongnu.org; Tue, 02 Jul 2013 12:44:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uu3gk-0001h7-Az for qemu-devel@nongnu.org; Tue, 02 Jul 2013 12:44:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu3gk-0001gv-2q for qemu-devel@nongnu.org; Tue, 02 Jul 2013 12:44:22 -0400 Message-ID: <51D3035A.1060605@redhat.com> Date: Tue, 02 Jul 2013 10:44:10 -0600 From: Eric Blake MIME-Version: 1.0 References: <1371644677-11041-1-git-send-email-akong@redhat.com> <878v1pqak4.fsf@codemonkey.ws> <51D2F1B3.1080903@redhat.com> <20130702153945.GZ2524@redhat.com> In-Reply-To: <20130702153945.GZ2524@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2MNFIWGCCJHNBLRFENRJT" Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Anthony Liguori , qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com, pbonzini@redhat.com, Amos Kong This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MNFIWGCCJHNBLRFENRJT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/02/2013 09:39 AM, Daniel P. Berrange wrote: >>> Maybe I'm being too meta here, but why not just return qapi-schema.js= on >>> as a string and call it as day? >> >> Because qapi-schema.json requires further parsing. For example, how i= s >> a client supposed to know that '*foo':'int' means that there is an >> argument named 'foo' but it is optional? The rule of thumb with QMP i= s >> that if you have to post-process JSON output, then the JSON was not >> designed correctly. >=20 > Arguably that rule of thumb would apply equally to the QEMU > build scripts which already parse qapi-schema.json. It could > be possible to normalize qapi-schema.json somewhat to remove > this 2-stage parsing if we went down this route. Indeed, I wouldn't mind a one-time pass over qapi-schema.json to make it follow a more rigid format if that made it easier to use it as-is with less post-processing. It won't be very nice to backport such a conversion, but I don't know how much distros are planning on backporting introspection in the first place. >=20 > I'm finding it hard to clearly see what the 2 different proposed > data formats look like against each other. Can someone give some > examples, showing the data that would need to be parsed in each > format, for a couple of examples. My proposal (but not quite what was implemented in _this_ version of Amos' patch) has been: qapi-schema.json: { 'command': 'add_client', 'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool', '*tls': 'bool' } } My proposal: =3D> { "execute": "query-qmp-schema", "arguments": { "name": "add_client" } } <=3D { "return": [ { "name": "add_client", "type": "command", "data": [ { "name": "protocol", "type": "str" }, { "name": "fdname", "type": "str" }, { "name": "skipauth", "type": "bool", "optional": true }, { "name": "tls", "type": "bool", "optional": true } ] } ] } Note that one other benefit of breaking out "optional" into its own dict member: we are free to expand the dict to add new members, such as a '*default':'str' member (present when "optional":true, and with the stringized value of the default value used if "name" is not present). Of course, to be able to express a default value, we already have to modify the syntax stored in qapi-schema.json in the first place, which takes us back to the argument of a one-time conversion of the .json file to actually use a more formal typing system in the first place. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2MNFIWGCCJHNBLRFENRJT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJR0wNaAAoJEKeha0olJ0NqaAQH/iQAK0fYfppk0AxfN7dJQCwJ +ufBHAC4NdRp+y6mzTltkbAx9f1xbFuqeD1yr4fWdk5C5/0BvSwArmENpWUa3f/o PvqC04XXLscuJPHPH74mASiRc2WSho065sZBZUgUfTZKe/nKJJ2siBYgYru9bvuE JTmzLtLJTUL8ecRuWeIuAVFSmZvF9GnoSMvPr+kQ/mK/nQIW9zc7oSlEB1A68W5i IWfxZxcXmm5aV9Yt2QjN1I1CpjWQVFeU/gwDGMKYFbZ2ljGh77GqKybrJ30cRJFk qF3Nn54Qqg8MOYvyLvOgebs22ddxMvi23UCmX7JBjvHYPwqrnnvrxqdjOX3Zd5k= =Ez07 -----END PGP SIGNATURE----- ------enig2MNFIWGCCJHNBLRFENRJT--