From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZN5hm-0003lT-1M for qemu-devel@nongnu.org; Wed, 05 Aug 2015 16:54:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZN5hj-0004pL-93 for qemu-devel@nongnu.org; Wed, 05 Aug 2015 16:54:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZN5hj-0004pC-17 for qemu-devel@nongnu.org; Wed, 05 Aug 2015 16:54:27 -0400 References: <1438703896-12553-1-git-send-email-armbru@redhat.com> <1438703896-12553-31-git-send-email-armbru@redhat.com> From: Eric Blake Message-ID: <55C277FD.1020105@redhat.com> Date: Wed, 5 Aug 2015 14:54:21 -0600 MIME-Version: 1.0 In-Reply-To: <1438703896-12553-31-git-send-email-armbru@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VcILEmsUca7kiHreIWtcVsDm2dfVDL6IL" Subject: Re: [Qemu-devel] [PATCH RFC v3 30/32] qapi: New QMP command query-schema for QMP schema introspection 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) --VcILEmsUca7kiHreIWtcVsDm2dfVDL6IL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/04/2015 09:58 AM, Markus Armbruster wrote: > * All type references are by name. >=20 > Dictionary argument/result or list result is an implicit type > definition. >=20 >=20 > * Clients should *not* look up types by name, because type names are > not ABI. Look up the command or event you're interested in, then > follow the references. >=20 > TODO Should we hide the type names to eliminate the temptation? [not sure this conversation belongs better on 32 than here] I was just experimenting with things, and noticed that our choice of array names might not be ideal for clients. We already discussed earlier in the series that the name 'intList' might collide (the parser currently rejects collisions with '*Kind', but not '*List'). But in addition to that, look at what happens here in this patch: "{ \"element-type\": \"str\", \"meta-type\": \"array\", \"name\": \"strList\" }, " "{ \"element-type\": \"BlockStats\", \"meta-type\": \"array\", \"name\": \"BlockStatsList\" }, " "{ \"members\": [{ \"name\": \"values\", \"type\": \"strList\" } ], \"meta-type\": \"object\", \"name\": \"SchemaInfoEnum\" }, " "{ \"arg-type\": \":obj-query-blockstats-arg\", \"meta-type\": \"command\", \"name\": \"query-blockstats\", \"ret-type\": \"BlockStatsList\" }, " and particularly what happens to it after patch 32 is applied: "{ \"element-type\": \"str\", \"meta-type\": \"array\", \"name\": \"270\" }, " "{ \"element-type\": \"179\", \"meta-type\": \"array\", \"name\": \"96\" }, " "{ \"members\": [{ \"name\": \"values\", \"type\": \"270\" } ], \"meta-type\": \"object\", \"name\": \"273\" }, " "{ \"arg-type\": \"95\", \"meta-type\": \"command\", \"name\": \"query-blockstats\", \"ret-type\": \"96\" }, " In order to learn the return type of query-blockstats (to see if a new member was added to the struct), I now have to query what type 96 is, see that it is an array, and then query what members type 179 has. And when dealing with type 273, I don't know whether to expect an array or an object for the "type" member until I look up type 270 (but I _do_ know not to expect an int, number, boolean, or null). What if we instead munged the name of array types in introspection output to be "[int]" or "[BlockStats]"; or, with type masking in place, "[int]" or "[179]"? As in the following for the above examples: "{ \"element-type\": \"str\", \"meta-type\": \"array\", \"name\": \"[str]\" }, " "{ \"element-type\": \"179\", \"meta-type\": \"array\", \"name\": \"[179]\" }, " "{ \"members\": [{ \"name\": \"values\", \"type\": \"[str]\" } ], \"meta-type\": \"object\", \"name\": \"273\" }, " "{ \"arg-type\": \"95\", \"meta-type\": \"command\", \"name\": \"query-blockstats\", \"ret-type\": \"[179]\" }, " This way, libvirt or other clients could take shortcuts: I know that the return of query-blockstats will be an array, and I only have to look up the single type 179 to learn what members will be in the struct of that array; likewise, when inspecting struct 273, I know that "type" is an array of builtin strings and not an array of dicts, without needing to do another type lookup. I've always mentioned that I'm not a fan of packing multiple pieces of information into a single JSON member (often a sign that the schema is not specific enough), but in this particular case, the names would still resolve without paying attention to the contents of the name. That is, we'd be providing extra information (whether a name starts with leading '[') that clients can optionally use to be more efficient, but which will not penalize clients that stick with the tried-and-true approach of finding the array member with the matching name (that is, if I chase "[179]", I will still learn that I need to look up "179"). And it gives us the nice property that the first character of a type specifies its JSON properties (letter=3D>builtin, [=3D>array, digit=3D>object), other t= han the magic "any". I still think we need to munge to '*List' internally (as in our qapi_free_*() functions, for example), but what I'm trying to propose is that we don't expose the '*List' naming convention through introspection. We'd also have to consider what this means for the technical possibility of any 2D array types. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --VcILEmsUca7kiHreIWtcVsDm2dfVDL6IL 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/ iQEcBAEBCAAGBQJVwnf9AAoJEKeha0olJ0NqAL4IAIXLMj0THVptCupuy/eGtsyF nTGVzCZg/X/N93x63cmtr6WvUSIIKelHTkG/xQNuCEahWaiMQGJHqRS/6t9lX/dX C2QE4xurD74gggf0afakKnrBMLu91nCYeTGYZr+dk8Hi1qqr3bGp759LVT+V/8Hm vIsHq3FKaQyUt7TJazvPo4XM/vD9AfZyRi7f+nl03LuYzipvpWUocthnldC2xC+0 uWm1RXDMzs2ffbLrb0PBxoFMwLlnZKzGdQgHcfPzGW8r/FDNDeLKTBdbcxi4UNFF abZ5eQwIkRf3uKdXuP/iVdkmWmRwNewajg/UfAujPtfTKuqDBchXLl07/VWj6+k= =TkRo -----END PGP SIGNATURE----- --VcILEmsUca7kiHreIWtcVsDm2dfVDL6IL--