From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKCOf-0003bN-H7 for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:26:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKCOc-000803-8Q for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:26:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKCOc-0007zn-21 for qemu-devel@nongnu.org; Tue, 28 Jul 2015 17:26:46 -0400 References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-48-git-send-email-armbru@redhat.com> <55B1B490.6000402@redhat.com> <55B65937.70205@redhat.com> <87mvygp1mo.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55B7F38F.4080604@redhat.com> Date: Tue, 28 Jul 2015 15:26:39 -0600 MIME-Version: 1.0 In-Reply-To: <87mvygp1mo.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V3OX7q9ArvAOjlWd4UjLTl9gB0DxMHFOv" 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) --V3OX7q9ArvAOjlWd4UjLTl9gB0DxMHFOv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/28/2015 12:39 PM, Markus Armbruster wrote: >=20 > Could do plain integer. I guess I started down the base32 road to > squeeze out a few more characters, then sabotaged myself by always usin= g > three base32 characters. >=20 >=20 > In the introspection schema, every 'str' that's really a type name need= s > to be replaced by 'int'. Sadly, our introspection union is based on 'name':'str', 'meta-type':'...' as the base members of the union; and that 'name' would be one of the places where we'd want an integer; so we probably have to stick to a string. That said, using a string-ized integer may be a bit more legible (for some reason, humans are better at reading decimal numbers than base32 numbers), and since no valid command or event starts with an integer, we could use the stringized integer directly without having to use a colon (in fact, for the first 999 types encountered, a stringized integer is shorter than the base32 compression + the leading colon for namespacing) :) >=20 > Should we later decide we don't want to hide type names after all, then= > backward compatibility will make it very hard to go back. Indeed - changing 'str' to 'int' in the schema is a much stronger commitment than leaving things 'str' but passing a stringized integer in that string. >=20 > I wouldn't expect clients to find stuff with a linear search. Use a > dictionary. Should be plenty fast enough for processing the schema. Requires more memory in the client to create that hash table on the one pass through the JSON - but as is often the case in computer science, asking the client to trade space for time is not too onerous. (Libvirt's current JSON parser does NOT create a hash table of the dictionaries that it reads, so libvirt would actually have to do two passes and/or update its use of libyajl into creating hash tables when appropriate - but that should not be a driving factor in your design.) >=20 >> 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 f= or >> referring to types. Of course, if we do this, life gets a lot trickie= r >> for adding filtering down to a subset of the overall schema (unless yo= u >> don't mind populating lots of 'null' entries for parts that get filter= ed >> 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 > Filtering is a headache I'd prefer to avoid. Well, since I've had most of the ideas about how filtering could even be done, I'm perfectly okay with you leaving the guts of filtering for me (or someone else) to do as a followup series; and even then, I first have to decide if it would help libvirt to have a filtered list. What's important for this series is that we haven't precluded the possibility of adding filtering later, and I think we've succeeded at that. And as for using raw integers to represent offsets into the returned JSON array, I think that is a bit too brittle; so I'm happy with forcing clients to create their own dictionary/hash lookup of string type names, even if the strings are munged to avoid leaking qapi types as non-ABI. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --V3OX7q9ArvAOjlWd4UjLTl9gB0DxMHFOv 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/OPAAoJEKeha0olJ0Nqqi8H/Rbfa7yZ15TEpjchgRXrJffk bCJQEwIZy3xQ/IbeDIomxyxTR61kT9BBaXGj4LIlaVyP4vC5VbClc0pZoeTu/o7U 7T4wdlqYHA7GihYurjaWXbc0QG5jtHDqqP9+dKmbNaSRlZHP73IKU5h3Z48gU9DP 6I7rkbKNfPYYP3QnlCsrzwPy8Jg2d908JijFyJ4DrrxQIjSZcbMVsKUZk9gRh8QU KlIj/9EGRzofEJfT0K+AHxuOG5n3ijZOAMFXe/Kp2ucLqUbUgIPQ5+oMzq0w/M6J Vswb09EgD/MqhqOwdsAnXGiNHIninoR1MJKNCjoFnSRADf0ou7F5AnmVESR+9bo= =LhqQ -----END PGP SIGNATURE----- --V3OX7q9ArvAOjlWd4UjLTl9gB0DxMHFOv--