RPC¶
fxv rpc runs a JSON-RPC 2.0 server that operates on a FlexVault workspace over stdin/stdout. A program starts the server once and makes as many calls as it needs, instead of running a separate fxv process per command.
This section is the protocol specification. This should outline the protocol in enough detail to allow implementors to create integrations in a straight forward manner.
It does not describe what the commands themselves do. The CLI Reference is canonical for that, and this section covers only what the RPC transport changes.
- Example Usage starts a server, makes a first call, and provides a simple client implementation in python.
- Protocol specifies the framing, the request and response objects, and the connection lifecycle.
- Methods lists every method the server answers and how each differs from the command line.
- Errors documents the error codes and what they contain.
When to use the RPC server¶
Each fxv command run from a shell starts a process, loads the workspace, does its work, and exits. That is the right model for interactive use, for scripts, and for CI, where commands run occasionally and process startup costs nothing that matters. Use the CLI for those, and see Integrate with CI and Automation for build system integration.
The RPC server suits a long-running program that queries the same workspace repeatedly: an editor or engine integration, a desktop client, or a tool that watches for changes. One server process handles the whole session.
The RPC server answers a subset of the CLI
The server currently answers six methods, covering fxv status, fxv history, and fxv user, plus three for managing the connection itself. Commands that change the workspace or the repository, including fxv snapshot, fxv publish, and fxv sync, are available only through the CLI. A client that needs them runs fxv as a command. See Methods for the current set.
Security¶
The server reads requests from its own standard input and writes responses to its own standard output. It does not open a socket, bind a port, or listen on a network.
There is no authentication
The RPC server has no authentication, no authorization, and no transport encryption. Any process that can write to the server's standard input has the same access to the workspace as the user who started it, including the storage credentials held in the workspace configuration.
A client must start the server itself and keep both pipes private to it. Do not forward the stream over a network, and do not expose it to another user on the same machine.