From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0HFk-0005Zf-4Q for qemu-devel@nongnu.org; Fri, 19 Jul 2013 16:26:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0HFj-0000ww-8G for qemu-devel@nongnu.org; Fri, 19 Jul 2013 16:26:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0HFj-0000wT-0n for qemu-devel@nongnu.org; Fri, 19 Jul 2013 16:26:11 -0400 Message-ID: <51E9A0E1.3000000@redhat.com> Date: Fri, 19 Jul 2013 14:26:09 -0600 From: Eric Blake MIME-Version: 1.0 References: <1373971062-28909-1-git-send-email-akong@redhat.com> <1373971062-28909-3-git-send-email-akong@redhat.com> <20130717163606.3ffe9676@redhat.com> In-Reply-To: <20130717163606.3ffe9676@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BxtHaK36rGOaNGLJdalWg4hSuWAUeSgFE" Subject: Re: [Qemu-devel] [PATCH v2 2/2] full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: pbonzini@redhat.com, aliguori@us.ibm.com, Amos Kong , qemu-devel@nongnu.org, armbru@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BxtHaK36rGOaNGLJdalWg4hSuWAUeSgFE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/17/2013 02:36 PM, Luiz Capitulino wrote: >> We need to parse all commands json definition, and generated a >> dynamical tree, QMP infrastructure will convert the tree to >> json string and return to QMP client. >> >> So here I defined a 'DataObject' type in qapi-schema.json, >> it's used to describe the dynamical dictionary/list/string. >=20 > I skimmed over the patch and made some comments, but my impression > is that this is getting too complex... Why did we move from letting > mngt query type by type (last version) to this version which returns > all commands and their input types? Does this satisfy libvirt needs? Libvirt can query once, and then browse through the (giant) reply as many times as needed to drill down to a full definition. The ability to filter by passing in a name to look up is a bonus, but not mandatory. I'm also working on a reply to the full patch. > You return only commands. That is, types are returned as part of the > command input. ErrorClass can't be queried then? I'm not judging, only > observing. >=20 > Eric, this is good enough for libvirt? It might be sufficient (after all, you can't use a type except by passing it as part of a command [argument or return] or event [which we still don't have converted into qapi...]). In one respect, it means that if we want to know if an optional field was added for command 'foo', we start by querying command foo; then regardless of what type names were used, we will see that in the results for the command. On the other hand, we've been arguing that qapi type names are part of the API, and that we shouldn't arbitrarily change type names (particularly not once introspection is in place). Thus, if I can query for the contents of type 'FooDict', that shaves a step from querying the structure of command 'foo' that uses the type 'FooDict'. In other words, it will "work" for libvirt, but it may not be optimal. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --BxtHaK36rGOaNGLJdalWg4hSuWAUeSgFE 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/ iQEcBAEBCAAGBQJR6aDhAAoJEKeha0olJ0NqWMMH+gMshxd6PJ/TMp3ZZxkdfs9u JyUdplMUcHpE4masS2JJ0H6R9150HkBIFOLVEm9703VrezVj99cnMGvWFJq/juCt V6ceyAH/5DAi+FiDtgRbVunC9zPXeiVBzHzo/aYyLa6DPFJQaGQVhEfkKSv6I6IN OakPzyrwGrOjqKV2CzvJUY3C6ldOazRCLbOtrt4Kme78fzGeBIilo10lCV+go+EN ZUiLZnkvQj33D1J3HV7FFOAUVWOGgc+M/BpdiQfCKRdTQE4cDxLZ6FqqUqpPg1YE 5qcQbFKq1KYmpD2BXYG3Pz3BckVyaDBrVhAsT86hduEAKkqbN9m1o3EKSwQ2z7s= =6LMk -----END PGP SIGNATURE----- --BxtHaK36rGOaNGLJdalWg4hSuWAUeSgFE--