From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YavR3-0005B2-Iq for qemu-devel@nongnu.org; Wed, 25 Mar 2015 20:14:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YavQx-0000Vz-SO for qemu-devel@nongnu.org; Wed, 25 Mar 2015 20:14:09 -0400 Received: from resqmta-po-07v.sys.comcast.net ([96.114.154.166]:50569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YavQx-0000Vn-O0 for qemu-devel@nongnu.org; Wed, 25 Mar 2015 20:14:03 -0400 From: Eric Blake Date: Wed, 25 Mar 2015 18:13:57 -0600 Message-Id: <1427328837-4406-6-git-send-email-eblake@redhat.com> In-Reply-To: <1427328837-4406-1-git-send-email-eblake@redhat.com> References: <1427328837-4406-1-git-send-email-eblake@redhat.com> Subject: [Qemu-devel] [PATCH 5/5] qapi: Fix QMP spec references to JSON List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: armbru@redhat.com I had assumed that 'id' of a command/return transaction could only be an integer, and therefore that 'json-value' meant integer, so I invented the term 'json-entity' to express a choice between json-object, json-string, and json-array. But in reality, the JSON RFC defines json-value as the combination of all other types, and the QMP parser currently accepts any JSON value that does not include a literal JSON null. So, clean up the docs to be consistent with the RFC. And while at it, use the newer version of the RFC. Signed-off-by: Eric Blake --- docs/qmp/qmp-spec.txt | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/qmp/qmp-spec.txt b/docs/qmp/qmp-spec.txt index 1fb642b..f7d8c30 100644 --- a/docs/qmp/qmp-spec.txt +++ b/docs/qmp/qmp-spec.txt @@ -28,10 +28,10 @@ following format: json-DATA-STRUCTURE-NAME -Where DATA-STRUCTURE-NAME is any valid JSON data structure, as defined by -the JSON standard: +Where DATA-STRUCTURE-NAME is any valid JSON data structure except the +'null' literal, as defined by the JSON standard: -http://www.ietf.org/rfc/rfc4627.txt +http://www.ietf.org/rfc/rfc7159.txt For convenience, json-object members mentioned in this document will be in a certain order. However, in real protocol usage they can be in @@ -92,7 +92,9 @@ The format for command execution is: execution of the command, it is optional when no arguments are required - The "id" member is a transaction identification associated with the command execution, it is optional and will be part of the response if - provided + provided. The "id" member can be any json-value that does not use a + json-null; however, most clients use a json-number incremented for + each successive command 2.4 Commands Responses ---------------------- @@ -105,13 +107,13 @@ of a command execution: success or error. The format of a success response is: -{ "return": json-entity, "id": json-value } +{ "return": json-value, "id": json-value } Where, - The "return" member contains the data returned by the command, which is defined on a per-command basis (usually a json-object or - json-array of json-objects, but sometimes a json-value, json-string, + json-array of json-objects, but sometimes a json-number, json-string, or json-array of json-strings); it is an empty json-object if the command does not return data - The "id" member contains the transaction identification associated -- 2.1.0