Resolve by JSON-RPC 2.0 call
JSON-RPC 2.0 is a relatively simple RPC codec which could be used as an alternative to by-process .
It's format of request(params...)
→ response(result or error)
matches the resolution mechanism well.
The obvious advantage of supporting a network call to a running process is that any start-up overhead in the process such as reading configuration or establishing a connection to a database can be easily managed. There are also security
It is expected that individual JSON-RPC 2.0 applications will be written specifically for the purpose of being connected to mod_resolve, just like programs written specifically for mod_resolve's by-process mechanism.
An open question is what transports to support - JSON-RPC 2.0 is transport-agnostic.
- JSON-RPC 2.0 wrapped in HTTP request/response, see JSON-RPC 2.0 Transport: HTTP. This is relatively widely implemented and there exists the proposed specification. Implementing HTTP is not trivial and may require libcurl.
- JSON-RPC 2.0 directly over an stream socket. Receivers must be able to parse exactly the next JSON object from the stream. This is not supported by all JSON libraries but there exist implementations for Python and C (https://github.com/rickardp/splitstream).
- JSON-RPC 2.0 directly over an stream socket with each JSON object separated by a newline character (JSON encoding must not use newlines). This is simpler to implement in many languages ("read from socket until newline") but does not seem to be widely used.
- JSON-RPC 2.0 with a content-length header. This is something used by VS Code.
The Redis module does contain code for connection management in threaded and non-threaded contexts. One of the approaches is to store open connections in a pool (ringbuffer). It would be nice to be able to test whether a connection is still valid when retrieved from the pool. Otherwise, broken connections may cause multiple errors when attempting to perform a request.
This mechanism would require a JSON library.
Configuration Interface
ResolveByJSONRPC FIELD OPTIONS ADDRESS METHOD PARAMA=PARAMA_VALUE_EXPR PARAMB=PARAMB_VALUE_EXPR
-
ADDRESS
andMETHOD
are static - Each parameter has a static name and the value is evaluated as an expression (at resolution time). The equal sign make the configuration more easily readable compared to separating by space.
This would perform a JSON-RPC method call with each parameter written as a field to the params
object.
The result field of the answer would be stringified and used as the resolved value.
Any error is logged and leads to a 500 or similar status code, which can be influenced by setting error.data.status
(status_code
, http_status
, ...) to a custom status.
Caching can be directly applied, however, the cache key and value structure must be adapted to match the JSON-RPC schema.