ipc: some user-visible changes to prepare for making all commands async

I wanted to put all commands through mpv_command_node_async() instead of
mpv_command_node(). Using synchronous commands over a synchronous
transport doesn't make sense anyway.

This would have used the request_id field in IPC requests as reply ID
for the async commands. But the latter need to be [u]int64, while the
former can be any type. To avoid that we need an extra lookup table for
mapping reply IDs to request_id values, we now require that request_id
fields are integers.

Since this would be an incompatible change, just deprecate non-integers
for now, and plan the change for a later time.

1 files changed, 9 insertions, 1 deletions

diff --git a/DOCS/man/ipc.rst b/DOCS/man/ipc.rst
index 1a5eadfe49..0c551e8706 100644
--- a/DOCS/man/ipc.rst
+++ b/DOCS/man/ipc.rst
@@ -108,7 +108,10 @@ Because events can occur at any time, it may be difficult at times to determine
 which response goes with which command. Commands may optionally include a
 ``request_id`` which, if provided in the command request, will be copied
 verbatim into the response. mpv does not intrepret the ``request_id`` in any
-way; it is solely for the use of the requester.
+way; it is solely for the use of the requester. The only requirement is that
+the ``request_id`` field must be an integer (a number without fractional parts
+in the range ``-2^63..2^63-1``). Using other types is deprecated and will
+currently show a warning. In the future, this will raise an error.
 
 For example, this request:
 
@@ -122,6 +125,11 @@ Would generate this response:
 
     { "error": "success", "data": 1.468135, "request_id": 100 }
 
+If you don't specify a ``request_id``, command replies will set it to 0.
+
+Commands may run asynchronously in the future, instead of blocking the  socket
+until a reply is sent.
+
 All commands, replies, and events are separated from each other with a line
 break character (``\n``).