From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yase1-00060V-FY for qemu-devel@nongnu.org; Wed, 25 Mar 2015 17:15:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yasdy-0002Wz-8z for qemu-devel@nongnu.org; Wed, 25 Mar 2015 17:15:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yasdy-0002Wj-2c for qemu-devel@nongnu.org; Wed, 25 Mar 2015 17:15:18 -0400 Message-ID: <55132564.3020604@redhat.com> Date: Wed, 25 Mar 2015 15:15:16 -0600 From: Eric Blake MIME-Version: 1.0 References: <1427227433-5030-1-git-send-email-eblake@redhat.com> <1427227433-5030-2-git-send-email-eblake@redhat.com> <87vbhpc4j7.fsf@blackfin.pond.sub.org> <55131689.8030107@redhat.com> In-Reply-To: <55131689.8030107@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NtMPD07eN5GwxIr4v6bgH1egW84UxxVVr" Subject: Re: [Qemu-devel] [PATCH v5 01/28] qapi: Document type-safety considerations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, wenchaoqemu@gmail.com, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NtMPD07eN5GwxIr4v6bgH1egW84UxxVVr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/25/2015 02:11 PM, Eric Blake wrote: >> The QObject types are QTYPE_NONE, QTYPE_QINT, QTYPE_QSTRING, >> QTYPE_QDICT, QTYPE_QLIST, QTYPE_QFLOAT, QTYPE_QBOOL, QTYPE_QERROR. >> >> The connections JSON string - QTYPE_QSTRING, JSON object - QTYPE_QDICT= , >> JSON array - QTYPE_QLIST and JSON boolean - QTYPE_QBOOL are obvious >> enough. >> >> If I remember correctly, our JSON parser chokes on the JSON keyword >> null. Yep, that is sadly still the case [1]: $ qemu-kvm -qmp stdio -nodefaults {"QMP": {"version": {"qemu": {"micro": 90, "minor": 2, "major": 2}, "package": " (qemu-2.3.0-0.1.rc0.fc21)"}, "capabilities": []}} {"execute":"qmp_capabilities","id":null} {"error": {"class": "GenericError", "desc": "Invalid JSON syntax"}} Patch 17 adds support for it to qapi schemas, but not to our JSON parser. I guess that's yet another task to be solved before we turn on argument defaults and introspection (as returning 'null' would be a logical solution for introspecting the default value of an optional string argument. On the other hand, we could argue that using 'null' in output of introspection still doesn't require the parser to accept 'null' on input; the output direction of introspection is different than the input direction of parsing a 'null' in user commands). >> >> That leaves just JSON numbers - QTYPE_QINT or QTYPE_QFLOAT. Can an >> anonymous union have a separate case for each of the two? Yes. Don't know why we'd want it, but the code currently handles it. That is, this compiles just fine: { 'alternate': 'Foo', 'data': { 'a': 'int', 'b': 'number' } } { 'command': 'bar', 'data': { 'value': 'Foo' } } allowing: {"execute":"bar", "arguments":{ "value":1 } } {"execute":"bar", "arguments":{ "value":1.0 } } as operating on uint64_t vs. double (in practice, since '1' is also valid input as a number, a double is sufficient without needing the alternative of a uint64_t, unless you are simultaneously worrying about precise integral values larger than 2**53 that lose data when converted to double, while still allowing for inputs larger than 2**63 via double) >>> The format of a success response is: >>> >>> -{ "return": json-object, "id": json-value } >>> +{ "return": json-entity, "id": json-value } >> >> Unlike the other json-FOOs we use, "entity" isn't defined in RFC4627. >> "value" is, and we already use json-value. What's the difference >> between the two? >=20 > Umm, when I wrote that, I was thinking "id":json-value meant integer, s= o > I wanted something that was not an integer. But sure enough, json-valu= e > is precisely the term I wanted to use: Well, given above at [1] that 'null' is a valid json-value but NOT accepted by our parser, I guess we are not quite accurate here. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --NtMPD07eN5GwxIr4v6bgH1egW84UxxVVr 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVEyVkAAoJEKeha0olJ0NqDNsH/2T5OyDNGqA1d4lCMkvpmt5Y ingnoy2yUg2a1XRp05g292/47+DGqvLSRY/cQrd7cw0j0/e19R7xOMKVCjgvZc3+ NeCzXm/9cjkPefNcuTwWEsj2XlkZyRFSJ5zLzmWBUoBugSHakUNwSalArkfYu0dv hL9zK1CZsZ3qinLi8YxWmazr0uTimBRy+6XHoge4HTuRzNGiVGDnXl9nthIRRIrV rJvEZUY09LKmj8SFopJ5NgoY/AVZPhzQyVzz6uCdxga1j9ZGHPhwiK6RO1OA5zyC UXtgDW0RPeqMOLqbyHRZZMeLq1LuC3TH7+kOunETLc6sZ3FnUc3qwXPwj2lKKZM= =kna5 -----END PGP SIGNATURE----- --NtMPD07eN5GwxIr4v6bgH1egW84UxxVVr--