RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/input/ipc.c

415 lines
13 KiB
C
Raw Normal View History

input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
/*
* This file is part of mpv.
*
Change 3 more files to LGPL
2016-01-20 14:43:56 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Change 3 more files to LGPL
2016-01-20 14:43:56 +00:00
* GNU Lesser General Public License for more details.
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
*
Change 3 more files to LGPL
2016-01-20 14:43:56 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
*/
#include "common/msg.h"
#include "input/input.h"
#include "misc/json.h"
node: move a mpv_node helper from ipc.c to shared code This particular one is needed in a following commit.
2018-05-12 12:48:24 +00:00
#include "misc/node.h"
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
#include "options/m_option.h"
ipc: decouple from MPContext Just a minor refactor to keep unneeded dependencies on the core low.
2014-10-19 14:44:33 +00:00
#include "options/options.h"
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
#include "options/path.h"
#include "player/client.h"
static mpv_node *mpv_node_array_get(mpv_node *src, int index)
{
if (src->format != MPV_FORMAT_NODE_ARRAY)
return NULL;
if (src->u.list->num < (index + 1))
return NULL;
return &src->u.list->values[index];
}
static void mpv_node_map_add(void *ta_parent, mpv_node *src, const char *key, mpv_node *val)
{
if (src->format != MPV_FORMAT_NODE_MAP)
return;
if (!src->u.list)
src->u.list = talloc_zero(ta_parent, mpv_node_list);
MP_TARRAY_GROW(src->u.list, src->u.list->keys, src->u.list->num);
MP_TARRAY_GROW(src->u.list, src->u.list->values, src->u.list->num);
src->u.list->keys[src->u.list->num] = talloc_strdup(ta_parent, key);
static const struct m_option type = { .type = CONF_TYPE_NODE };
m_option_get_node(&type, ta_parent, &src->u.list->values[src->u.list->num], val);
src->u.list->num++;
}
static void mpv_node_map_add_null(void *ta_parent, mpv_node *src, const char *key)
{
mpv_node val_node = {.format = MPV_FORMAT_NONE};
mpv_node_map_add(ta_parent, src, key, &val_node);
}
static void mpv_node_map_add_int64(void *ta_parent, mpv_node *src, const char *key, int64_t val)
{
mpv_node val_node = {.format = MPV_FORMAT_INT64, .u.int64 = val};
mpv_node_map_add(ta_parent, src, key, &val_node);
}
static void mpv_node_map_add_string(void *ta_parent, mpv_node *src, const char *key, const char *val)
{
mpv_node val_node = {.format = MPV_FORMAT_STRING, .u.string = (char*)val};
mpv_node_map_add(ta_parent, src, key, &val_node);
}
ipc: implement asynchronous commands I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
2020-02-23 23:14:54 +00:00
// This is supposed to write a reply that looks like "normal" command execution.
static void mpv_format_command_reply(void *ta_parent, mpv_event *event,
mpv_node *dst)
{
assert(event->event_id == MPV_EVENT_COMMAND_REPLY);
mpv_event_command *cmd = event->data;
mpv_node_map_add_int64(ta_parent, dst, "request_id", event->reply_userdata);
mpv_node_map_add_string(ta_parent, dst, "error",
mpv_error_string(event->error));
mpv_node_map_add(ta_parent, dst, "data", &cmd->result);
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
char *mp_json_encode_event(mpv_event *event)
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
{
void *ta_parent = talloc_new(NULL);
client API, lua, ipc: unify event struct return Both Lua and the JSON IPC code need to convert the mpv_event struct (and everything it points to) to Lua tables or JSON. I was getting sick of having to make the same changes to Lua and IPC. Do what has been done everywhere else, and let the core handle this by going through mpv_node (which is supposed to serve both Lua tables and JSON, and potentially other scripting language backends). Expose it as new libmpv API function. The new API is still a bit "rough" and support for other event types might be added in the future. This silently adds support for the playlist_entry_id fields to both Lua and JSON IPC. There is a small API change for Lua; I don't think this matters, so I didn't care about compatibility. The new code in client.c is mashed up from the Lua and the IPC code. The manpage additions are moved from the Lua docs, and made slightly more "general". Some danger for unintended regressions both in Lua and IPC. Also damn these node functions suck, expect crashes due to UB. Not sure why this became more code instead of less compared to before (according to the diff stat), even though some code duplication across Lua and IPC was removed. Software development sucks.
2020-03-21 18:31:58 +00:00
struct mpv_node event_node;
if (event->event_id == MPV_EVENT_COMMAND_REPLY) {
event_node = (mpv_node){.format = MPV_FORMAT_NODE_MAP, .u.list = NULL};
mpv_format_command_reply(ta_parent, event, &event_node);
} else {
mpv_event_to_node(&event_node, event);
// Abuse mpv_event_to_node() internals.
talloc_steal(ta_parent, node_get_alloc(&event_node));
}
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
char *output = talloc_strdup(NULL, "");
json_write(&output, &event_node);
output = ta_talloc_strdup_append(output, "\n");
talloc_free(ta_parent);
return output;
}
ipc: accept both JSON and "old" commands Minimizes the differences between --input-file and --input-unix-socket.
2014-10-19 19:38:43 +00:00
// Function is allowed to modify src[n].
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
static char *json_execute_command(struct mpv_handle *client, void *ta_parent,
ipc: accept both JSON and "old" commands Minimizes the differences between --input-file and --input-unix-socket.
2014-10-19 19:38:43 +00:00
char *src)
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
{
int rc;
const char *cmd = NULL;
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
struct mp_log *log = mp_client_get_log(client);
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
mpv_node msg_node;
mpv_node reply_node = {.format = MPV_FORMAT_NODE_MAP, .u.list = NULL};
ipc: fix undefined behavior in some error cases goto jumping over an initialization.
2015-07-05 22:08:29 +00:00
mpv_node *reqid_node = NULL;
ipc: implement asynchronous commands I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
2020-02-23 23:14:54 +00:00
int64_t reqid = 0;
mpv_node *async_node = NULL;
bool async = false;
bool send_reply = true;
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
ipc: raise json nesting limit Fixes the issue pointed out in #4394.
2017-05-03 18:47:11 +00:00
rc = json_parse(ta_parent, &msg_node, &src, 50);
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
if (rc < 0) {
ipc: raise json nesting limit Fixes the issue pointed out in #4394.
2017-05-03 18:47:11 +00:00
mp_err(log, "malformed JSON received: '%s'\n", src);
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (msg_node.format != MPV_FORMAT_NODE_MAP) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: implement asynchronous commands I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
2020-02-23 23:14:54 +00:00
async_node = node_map_get(&msg_node, "async");
if (async_node) {
if (async_node->format != MPV_FORMAT_FLAG) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
async = async_node->u.flag;
}
node: move a mpv_node helper from ipc.c to shared code This particular one is needed in a following commit.
2018-05-12 12:48:24 +00:00
reqid_node = node_map_get(&msg_node, "request_id");
ipc: implement asynchronous commands I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
2020-02-23 23:14:54 +00:00
if (reqid_node) {
if (reqid_node->format == MPV_FORMAT_INT64) {
reqid = reqid_node->u.int64;
} else if (async) {
mp_err(log, "'request_id' must be an integer for async commands.\n");
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
} else {
mp_warn(log, "'request_id' must be an integer. Using other types is "
"deprecated and will trigger an error in the future!\n");
}
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.
2018-05-13 10:46:50 +00:00
}
ipc: add request_id to json 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.
2015-07-03 17:51:46 +00:00
node: move a mpv_node helper from ipc.c to shared code This particular one is needed in a following commit.
2018-05-12 12:48:24 +00:00
mpv_node *cmd_node = node_map_get(&msg_node, "command");
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
if (!cmd_node) {
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
if (cmd_node->format == MPV_FORMAT_NODE_ARRAY) {
mpv_node *cmd_str_node = mpv_node_array_get(cmd_node, 0);
if (!cmd_str_node || (cmd_str_node->format != MPV_FORMAT_STRING)) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
cmd = cmd_str_node->u.string;
}
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
if (cmd && !strcmp("client_name", cmd)) {
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
const char *client_name = mpv_client_name(client);
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
mpv_node_map_add_string(ta_parent, &reply_node, "data", client_name);
rc = MPV_ERROR_SUCCESS;
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && !strcmp("get_time_us", cmd)) {
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
int64_t time_us = mpv_get_time_us(client);
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
mpv_node_map_add_int64(ta_parent, &reply_node, "data", time_us);
rc = MPV_ERROR_SUCCESS;
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && !strcmp("get_version", cmd)) {
ipc: add a command to retrieve API version
2014-11-01 13:13:05 +00:00
int64_t ver = mpv_client_api_version();
mpv_node_map_add_int64(ta_parent, &reply_node, "data", ver);
rc = MPV_ERROR_SUCCESS;
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && !strcmp("get_property", cmd)) {
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
mpv_node result_node;
if (cmd_node->u.list->num != 2) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[1].format != MPV_FORMAT_STRING) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
rc = mpv_get_property(client, cmd_node->u.list->values[1].u.string,
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
MPV_FORMAT_NODE, &result_node);
if (rc >= 0) {
mpv_node_map_add(ta_parent, &reply_node, "data", &result_node);
mpv_free_node_contents(&result_node);
}
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && !strcmp("get_property_string", cmd)) {
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
if (cmd_node->u.list->num != 2) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[1].format != MPV_FORMAT_STRING) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
char *result = mpv_get_property_string(client,
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
cmd_node->u.list->values[1].u.string);
ipc: cosmetic: switch a negated if/else
2018-05-13 10:21:00 +00:00
if (result) {
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
mpv_node_map_add_string(ta_parent, &reply_node, "data", result);
mpv_free(result);
ipc: cosmetic: switch a negated if/else
2018-05-13 10:21:00 +00:00
} else {
mpv_node_map_add_null(ta_parent, &reply_node, "data");
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
}
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && (!strcmp("set_property", cmd) ||
!strcmp("set_property_string", cmd)))
ipc: alias set_property_string to set_property The only effective difference is that the former explicitly checks whether the JSON value type is string, and errors out if not. The rest is exactly the same (mpv_set_property_string is mpv_set_property with MPV_FORMAT_STRING). It seems silly to keep this, so just remove it.
2018-05-13 10:19:11 +00:00
{
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
if (cmd_node->u.list->num != 3) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[1].format != MPV_FORMAT_STRING) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
rc = mpv_set_property(client, cmd_node->u.list->values[1].u.string,
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
MPV_FORMAT_NODE, &cmd_node->u.list->values[2]);
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && !strcmp("observe_property", cmd)) {
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
if (cmd_node->u.list->num != 3) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[1].format != MPV_FORMAT_INT64) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[2].format != MPV_FORMAT_STRING) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
rc = mpv_observe_property(client,
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
cmd_node->u.list->values[1].u.int64,
cmd_node->u.list->values[2].u.string,
MPV_FORMAT_NODE);
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && !strcmp("observe_property_string", cmd)) {
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
if (cmd_node->u.list->num != 3) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[1].format != MPV_FORMAT_INT64) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[2].format != MPV_FORMAT_STRING) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
rc = mpv_observe_property(client,
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
cmd_node->u.list->values[1].u.int64,
cmd_node->u.list->values[2].u.string,
MPV_FORMAT_STRING);
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && !strcmp("unobserve_property", cmd)) {
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
if (cmd_node->u.list->num != 2) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[1].format != MPV_FORMAT_INT64) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
rc = mpv_unobserve_property(client,
cmd_node->u.list->values[1].u.int64);
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && !strcmp("request_log_messages", cmd)) {
ipc: make it possible to receive log messages The receiving part was implemented, but since no messages are enabled by default, it couldn't be used.
2014-11-01 14:36:30 +00:00
if (cmd_node->u.list->num != 2) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[1].format != MPV_FORMAT_STRING) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
rc = mpv_request_log_messages(client,
ipc: make it possible to receive log messages The receiving part was implemented, but since no messages are enabled by default, it couldn't be used.
2014-11-01 14:36:30 +00:00
cmd_node->u.list->values[1].u.string);
ipc: allow sending commands with named arguments This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
2020-02-23 23:31:46 +00:00
} else if (cmd && (!strcmp("enable_event", cmd) ||
!strcmp("disable_event", cmd)))
ipc: add enable_event and disable_event commands This was requested.
2014-12-24 13:32:02 +00:00
{
bool enable = !strcmp("enable_event", cmd);
if (cmd_node->u.list->num != 2) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
if (cmd_node->u.list->values[1].format != MPV_FORMAT_STRING) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
char *name = cmd_node->u.list->values[1].u.string;
if (strcmp(name, "all") == 0) {
for (int n = 0; n < 64; n++)
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
mpv_request_event(client, n, enable);
ipc: add enable_event and disable_event commands This was requested.
2014-12-24 13:32:02 +00:00
rc = MPV_ERROR_SUCCESS;
} else {
int event = -1;
for (int n = 0; n < 64; n++) {
const char *evname = mpv_event_name(n);
if (evname && strcmp(evname, name) == 0)
event = n;
}
if (event < 0) {
rc = MPV_ERROR_INVALID_PARAMETER;
goto error;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
rc = mpv_request_event(client, event, enable);
ipc: add enable_event and disable_event commands This was requested.
2014-12-24 13:32:02 +00:00
}
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
} else {
ipc: fix recently added memory leak Sucks.
2020-03-26 23:07:03 +00:00
mpv_node result_node = {0};
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
ipc: implement asynchronous commands I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
2020-02-23 23:14:54 +00:00
if (async) {
rc = mpv_command_node_async(client, reqid, cmd_node);
if (rc >= 0)
send_reply = false;
} else {
rc = mpv_command_node(client, cmd_node, &result_node);
if (rc >= 0)
mpv_node_map_add(ta_parent, &reply_node, "data", &result_node);
}
ipc: fix recently added memory leak Sucks.
2020-03-26 23:07:03 +00:00
mpv_free_node_contents(&result_node);
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
}
error:
ipc: add request_id to json 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.
2015-07-03 17:51:46 +00:00
/* If the request contains a "request_id", copy it back into the response.
* This makes it easier on the requester to match up the IPC results with
* the original requests.
*/
if (reqid_node) {
mpv_node_map_add(ta_parent, &reply_node, "request_id", reqid_node);
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.
2018-05-13 10:46:50 +00:00
} else {
mpv_node_map_add_int64(ta_parent, &reply_node, "request_id", 0);
ipc: add request_id to json 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.
2015-07-03 17:51:46 +00:00
}
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
mpv_node_map_add_string(ta_parent, &reply_node, "error", mpv_error_string(rc));
ipc: accept both JSON and "old" commands Minimizes the differences between --input-file and --input-unix-socket.
2014-10-19 19:38:43 +00:00
char *output = talloc_strdup(ta_parent, "");
ipc: implement asynchronous commands I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
2020-02-23 23:14:54 +00:00
if (send_reply) {
json_write(&output, &reply_node);
output = ta_talloc_strdup_append(output, "\n");
}
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
return output;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
static char *text_execute_command(struct mpv_handle *client, void *tmp, char *src)
input: implement --input-file on unix using the IPC support
2014-10-15 15:48:47 +00:00
{
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
mpv_command_string(client, src);
input: implement --input-file on unix using the IPC support
2014-10-15 15:48:47 +00:00
return NULL;
}
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
char *mp_ipc_consume_next_command(struct mpv_handle *client, void *ctx, bstr *buf)
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
{
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
void *tmp = talloc_new(NULL);
input: if FD is not writable, just don't write to the FD This is for the case if the FD is a uni-directional pipe.
2015-02-26 21:06:40 +00:00
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
bstr rest;
bstr line = bstr_getline(*buf, &rest);
char *line0 = bstrto0(tmp, line);
talloc_steal(tmp, buf->start);
*buf = bstrdup(NULL, rest);
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
json_skip_whitespace(&line0);
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
char *reply_msg = NULL;
if (line0[0] == '\0' || line0[0] == '#') {
// skip
} else if (line0[0] == '{') {
reply_msg = json_execute_command(client, tmp, line0);
ipc: make sure --input-file=/dev/stdin always works It's not necessarily available on Unix systems other than Linux (sigh).
2014-11-07 08:50:29 +00:00
} else {
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
reply_msg = text_execute_command(client, tmp, line0);
ipc: make sure --input-file=/dev/stdin always works It's not necessarily available on Unix systems other than Linux (sigh).
2014-11-07 08:50:29 +00:00
}
ipc: fix minor error cleanup issues The ipc_thread can exit any time, and will free the mp_ipc_ctx when doing this, leaving a dangling pointer. This was somewhat handled in the original commit by setting mpctx->ipc_ctx to NULL when the thread exited, but that was still a race condition. Handle it by freeing most things after joining the ipc_thread. This means some resources will not be freed until player exit, but that should be ok (it's an exceptional error situation). Also, actually close the pipe FDs in mp_init_ipc() on another error path.
2014-10-19 19:04:38 +00:00
ipc: add Windows implementation with named pipes This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
2016-03-17 08:27:30 +00:00
talloc_steal(ctx, reply_msg);
talloc_free(tmp);
return reply_msg;
input: implement JSON-based IPC protocol
2014-10-16 09:48:18 +00:00
}