From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJlNj-0003Nl-HP for qemu-devel@nongnu.org; Mon, 27 Jul 2015 12:36:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJlNf-0004Jn-E7 for qemu-devel@nongnu.org; Mon, 27 Jul 2015 12:36:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJlNf-0004JN-6N for qemu-devel@nongnu.org; Mon, 27 Jul 2015 12:35:59 -0400 References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-48-git-send-email-armbru@redhat.com> <55B1B490.6000402@redhat.com> From: Eric Blake Message-ID: <55B65937.70205@redhat.com> Date: Mon, 27 Jul 2015 10:15:51 -0600 MIME-Version: 1.0 In-Reply-To: <55B1B490.6000402@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DAx4cKnneI4l9oKm4cIddG2dlTR6rMj1Q" 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 , qemu-devel@nongnu.org Cc: kwolf@redhat.com, berto@igalia.com, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DAx4cKnneI4l9oKm4cIddG2dlTR6rMj1Q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/23/2015 09:44 PM, Eric Blake wrote: > 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. >=20 > 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 >> =20 >> +import string >> from qapi import * >> =20 >> +def _b32digit(num): >> + return (string.lowercase + string.digits[2:])[num] >=20 > This feels a bit too magic for me to decipher late at night. Looking at this again after a weekend: you are doing a poor-man's base32 encoding that maps a number between 0 and 31 inclusive to "abc...xyz234567" (skipping 0 and 1 due to some fonts being unclear with O and l/I). Question - if we really want to compress things down to an integer, would it make any more sense to actually use an integer instead of a string encoding of an unusual base32 alphabet (that is, output an integer instead of a string)? Conversely, if we are going to insist on an encoding, can we use the RFC4648 base32 definition (upper case, not lower case)? More thoughts: I'm probably okay with hiding type names (since they aren't ABI), but can we come up with an output format that is more conducive for use by the end user? Considering that we are returning a JSON array, what if we return the integer offset of the type as recorded in the returned array. That is, if we have { 'name':'ACPI_DEVICE_OST', 'meta-type':'event', 'data':100 } in slot [0] of the return array, then { 'name': ':aaa', 'meta-type': 'object', 'members': [ { 'name': 'info', 'type': 250 } ] } in slot [100], then the definition for type ':ae5' in slot [250], and so forth. My goal here is not a topologically sorted return array, so much as a shorthand where using an integer for a type-name means that we can quickly locate that offset within the JSON array, instead of having to do a linear search over the entire array for an array member that has the matching name. Or if type names are truly unimportant, then omit names for type elements (by making name optional in the introspection qapi description), and using ONLY offsets in the returned JSON array for referring to types. Of course, if we do this, life gets a lot trickier for adding filtering down to a subset of the overall schema (unless you don't mind populating lots of 'null' entries for parts that get filtered out so that the parts that are displayed are always at the same array offset, just with less overall output bulk due to the filtering). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --DAx4cKnneI4l9oKm4cIddG2dlTR6rMj1Q 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/ iQEcBAEBCAAGBQJVtlk3AAoJEKeha0olJ0Nq4OcH/23+OyqAoBV1VAelB65MII+y 8paBmZHx/k4c2L70zLKtnkZxfOUzSWkTiHZ5Q+JTH5ohYsWaDYVJOQFbR2DJzMzh VxvVkU6q1zKiZqVtb29f32HzOgq5Ysql+OcuT5lCn9dFHa+ItcPgfAVvpP9kZBFD 99uQIBxkd5Jgpg5QNn1+lszJ5WZ6tiT3ohX3QibyB0y1A5mNqrM79hwoxAcm3Dgq Vs1kMAnt7X6Jhe46jxOAeESflAPwqZ2lACZ+XoL9A+mbmdFOUi2Gxh6O+45sVpmA aFn7MvduqpM2oYLdMK/eOHop0BojlaaxsbvnIX1ourWIt/Z5RdXyJFdM09ZK1Kg= =8AHf -----END PGP SIGNATURE----- --DAx4cKnneI4l9oKm4cIddG2dlTR6rMj1Q--