feat: allow to connect a python rpc-client to an rpc-server via a unix FIFO file instead of subprocess #7535
Conversation
hpk42
force-pushed
the
hpk/rpc-pipes
branch
10 times, most recently
from
510fbee to
1ab8329
Compare
hpk42
changed the title
| fn_response_fifo = tmp_path.joinpath("response_fifo") | ||
| os.mkfifo(fn_request_fifo) | ||
| os.mkfifo(fn_response_fifo) | ||
| popen = subprocess.Popen(f"deltachat-rpc-server <{fn_request_fifo} >{fn_response_fifo}", shell=True) |
There was a problem hiding this comment.
For any real use FIFOs should likely be replaced with the UNIX socket, which exists on all platforms (including Windows) and can handle multiple connections.
There was a problem hiding this comment.
makes sense to rather go for UNIX sockets, but i think it's fine to merge this PR already. Shouldn't be too hard to write another RpcUNIXSocket subclass after #7545 is done.
| """ | ||
| from .client import Bot | ||
|
|
||
| _run_cli(Bot, hooks, argv, **kwargs) |
There was a problem hiding this comment.
Don't know if it is actually unused e.g. for rpc_server_path, at least the documentation should be updated.
There was a problem hiding this comment.
rpc_server_path was recently introduced. we can re-introduce **kwargs here if actually needed. Passing **kwargs all around makes reasoning about what happens harder in my experience.
There was a problem hiding this comment.
the reason **kwargs existed in the past was to be able to control the created process, ex. IIRC TUI clients need to tweak it so stderr don't dirty the screen,
I am talking about the removal in the Rpc class, but other approaches like allowing to pass a Popen directly to the start method in RpcProcess would also work I guess
also internally refactors rpc.py a bit and strikes unneccessary
**kwargs