From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKCU1-0005o4-Ei for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:32:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKCTw-0001vV-Fo for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:32:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50793) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKCTw-0001uv-8Y for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:32:16 -0400 References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-48-git-send-email-armbru@redhat.com> <55B1B490.6000402@redhat.com> <87wpxkp2bp.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55B7F4DE.3040807@redhat.com> Date: Tue, 28 Jul 2015 15:32:14 -0600 MIME-Version: 1.0 In-Reply-To: <87wpxkp2bp.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uGTEiBHe9LX1a1SEsArpPvGQ5AUjgOdqM" Subject: Re: [Qemu-devel] [PATCH RFC v2 47/47] qapi-introspect: Hide type names List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uGTEiBHe9LX1a1SEsArpPvGQ5AUjgOdqM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/28/2015 12:24 PM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> On 07/01/2015 02:22 PM, Markus Armbruster wrote: >>> To eliminate the temptation for clients to look up types by name >>> (which are not ABI), replace all type names by meaningless strings. >>> >>> Reduces output of query-schema by 9 out of 80KiB. >> >> I'm not sure whether I like this or not. It does make sense from the >> perspective of forcing clients to stick to ABI queries, but makes it a= >> bit harder to navigate things except by automated scripts. >=20 > Yes. I'm not sure it's a good idea. If we decide to hide types this > way, then I'd find an option to generate without type hiding useful. As in, an optional boolean flag to the QMP command that requests whether to get compact output with hidden names vs. full output with qapi names exposed (but then, are we storing TWO copies of the introspection strings)? Or merely as in the generated qmp-introspect.c file having strategic comments so that reading _that_ file lets you see the type names, even if they don't get passed on to the end user? > What the patch adds: >=20 > Move the introspection information for the non-types out of the way > before the loop, append the information on types afterwards. The resul= t > is now in jsons rather than self.jsons (see the next patch hunk). I did notice that; pre-patch interleaved commands and types all according to a global namespace, while post-patch sank all types to the bottom. Interestingly enough, if libvirt is going to query what features a command has, it will first find the command (in the first half of the returned array), then resolve the types used by that command until it learns if the member is present (whether new enum value or added dictionary member) - so there is that slight optimization that if we guarantee that types are always output last, then libvirt doesn't have to start generating its own hash table lookup of types until the first type is seen, after already learning everything it needed from the earlier command listings. >=20 > Why it does that: >=20 > With the funny typenames, sorting everything by name results in a mess.= > Keeping non-types and types separate is less of a mess. You do have a point there - as soon as we introduce name aliases, the aliases are unlikely to sort in the same manner as the original types, particularly if we generate the aliases based solely on what order we detected that those particular types were in use. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --uGTEiBHe9LX1a1SEsArpPvGQ5AUjgOdqM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVt/TeAAoJEKeha0olJ0NqUZcH/0oZywVMLSf68IGCAMvo0IuP h58F+Ie02RbEb6bowoh4ESYLK9m0nhZ8FhEjHiN8rGSmBcvBJFMDcKKwX+QukdQ7 UdcdO/Z82qGgxlqbFQT6APOaG0SRH0UFgzo+grTEwJ4qXdmPX8xYV5lg7Ka4oBGZ 5NsxINfUPGc0xBMWIpKEgsGNDdDgPg147QbjRihVrGf86CQ4T4DjCZdhpQGLAaKq R6gsDA/6Ow+9LfXiolnVqnaTCw67uzNLB7DcmVBACVLkxAucLgy4eCIOQhz2OrOD beV9YOVjj7og5uMqxA9Adet6VWGYBUqGMAI9zg2vvPWjE43BpLTmapB9EoIc5zw= =8xJF -----END PGP SIGNATURE----- --uGTEiBHe9LX1a1SEsArpPvGQ5AUjgOdqM--