From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu42r-00039p-Jw for qemu-devel@nongnu.org; Tue, 02 Jul 2013 13:07:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uu42n-0003UH-JT for qemu-devel@nongnu.org; Tue, 02 Jul 2013 13:07:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu42n-0003U9-B5 for qemu-devel@nongnu.org; Tue, 02 Jul 2013 13:07:09 -0400 Message-ID: <51D308A1.7080604@redhat.com> Date: Tue, 02 Jul 2013 11:06:41 -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> <51D3035A.1060605@redhat.com> <1408396387.2128564.1372784481475.JavaMail.root@redhat.com> In-Reply-To: <1408396387.2128564.1372784481475.JavaMail.root@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2NEIADHBLVRQGUVOMNQFN" Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , mdroth , qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com, Amos Kong This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NEIADHBLVRQGUVOMNQFN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/02/2013 11:01 AM, Paolo Bonzini wrote: >>> 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 > How would the schema look like after this "one-time pass"? >=20 > This: >=20 >> [ >> { "name": "protocol", >> "type": "str" }, >> { "name": "fdname", >> "type": "str" }, >> { "name": "skipauth", >> "type": "bool", >> "optional": true }, >> { "name": "tls", >> "type": "bool", >> "optional": true } >> ] >=20 > Looks quite awful for a human to write and read. Which puts us back in favor of my original argument that keeping qapi-schema.json compact for human use, while expanding the QMP output to be verbose for machine use, is probably what we'll have to live with. While it is easy to document shortcuts that the qapi parser can use when converting .json to code, it is harder to require that all other QMP clients must implement those same shortcuts, instead of having things already directly represented. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2NEIADHBLVRQGUVOMNQFN 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/ iQEcBAEBCAAGBQJR0wihAAoJEKeha0olJ0NqdkAH/jhfL8w3uquOVTxxqkeHbivm LqdC01fHfz3O+vhZsOaRPKq/kOeVL4kE4l0S7Gc64eJVNsEN2rS0q4xa7sQjztld t1cqlvGuG6Buk7VlvmlngKAy7UiADtxrlqFKOrQUTShIHz8o7C2yuyLoNLUXop2E 8/Zvc1M8G1kbX0DVPghZwb4i+zcmgvuB227Gtm6hOPvkSHygFxsiKU1DOxWYkRWn VED0QYLX4tlzDT0sqD+2fFonv1PPpGCvulBKD7dodUtAEjUrxYmseaTzf18lsRzB GZefMbimolAzA8urROYg6ol7TkUl25C0/hfrFHlApPUfYV2VLxIgW8lXHI8Yxo8= =H84c -----END PGP SIGNATURE----- ------enig2NEIADHBLVRQGUVOMNQFN--