summaryrefslogtreecommitdiffstats
path: root/DOCS/man/ipc.rst
Commit message (Collapse)AuthorAgeFilesLines
* manpage: document tricky issue with IPC observe_property commandwm42017-05-161-0/+8
| | | | Seems like people get confused by this.
* client API: turn mpv_suspend() and mpv_resume() into stubswm42016-11-221-14/+0
| | | | | | | | | | | As threatened by the API changes document. This commit also removes or stubs equivalent calls in IPC and Lua scripting. The stubs are left to maintain ABI compatibility. The semantics of the API functions have been close enough to doing nothing that this probably won't even break existing API users. Probably.
* client API: declare mpv_suspend/mpv_resume deprecatedwm42016-09-161-0/+4
| | | | | | | They're useless, and I have no idea what they're actually supposed to do (wrt. pending input processing changes). Also remove their implicit uses from the IPC handlers.
* Use - as command-name separator everywhereTimotej Lazar2016-07-141-2/+2
| | | | | | | Old-style commands using _ as separator (e.g. show_progress) were still used in some places, including documentation and configuration files. This commit updates all such instances to the new style (show-progress) so that commands are easier to find in the manual.
* man: ipc: update for named pipe IPC on WindowsJames Ross-Gowan2016-03-231-7/+32
|
* man: fix grammar issuesMartin Herkt2015-12-191-3/+5
|
* ipc: add request_id to jsonPreston Hunt2015-07-031-0/+18
| | | | | | | | | | | | If the request contains a "request_id", copy it back into the response. There is no interpretation of the request_id value by mpv; the only purpose is to make it easier on the requester by providing an ability to match up responses with requests. Because the IPC mechanism sends events continously, it's possible for the response to a request to arrive several events after the request was made. This can make it very difficult on the requester to determine which response goes to which request.
* manpage: ipc: make requirements for newlines more explicitwm42015-03-231-0/+3
| | | | Clarifying because someone asked.
* manpage: ipc: add a socat examplewm42015-02-211-3/+33
| | | | Requested, and should be quite good at giving an overview how it works.
* manpage: ipc: suggest --idlewm42015-02-091-1/+2
|
* ipc: add enable_event and disable_event commandswm42014-12-241-0/+8
| | | | This was requested.
* ipc: make it possible to receive log messageswm42014-11-011-0/+10
| | | | | The receiving part was implemented, but since no messages are enabled by default, it couldn't be used.
* ipc: add a command to retrieve API versionwm42014-11-011-0/+4
|
* manpage: ipc: fix command name for observe_propertywm42014-11-011-1/+1
|
* manpage: ipc: comment about invalid UTF-8wm42014-10-231-0/+12
| | | | | | | | | | | | | | | | | | | | Some rationale for the documented/suggested behavior: It's not really clear what to do with invalid UTF-8, since JSON simply can't transport this information. Maybe you could transfer such strings as byte arrays, but that would be very verbose and inconvenient, and would pose the problem that it's hard to distinguish between strings encoded in this way and actual arrays. There are many other ways how this could be handled. For example, you could replace invalid sequences with '?'. Or you could do it like Python, and use certain reserved unicode codepoints to "tunnel" through invalid bytes. Which of these works really depends on the application. And since this can be done entirely on the byte level (invalid UTF-8 sequences can appear only in strings in our case), it's best to leave this to the receiver.
* manpage: ipc: mention the socat toolwm42014-10-191-1/+2
| | | | | | | | This is not realy obvious, so I assume this is a helpful hint. Although the usefulness of such an approach is probably influenced by the fact that the player might send events that arrive in the short window while the socket is connected.
* ipc: skip empty and commented lineswm42014-10-191-1/+5
|
* ipc: accept both JSON and "old" commandswm42014-10-191-0/+4
| | | | Minimizes the differences between --input-file and --input-unix-socket.
* manpage: ipc: explain security implicationswm42014-10-171-0/+8
| | | | | | It's kind of obvious, since the protocol by design has to allow you to read (loadfile) and write (screenshot_to) random files, but better make it explicit so that nobody accidentally does something insecure.
* manpage: add JSON IPC documentationAlessandro Ghedini2014-10-171-0/+140
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 04:23:01 +0000