Documentation unclear on how scli integrates with signal-cli

[ppar]

signal-cli has a wealth of options on how to run it:

• ad-hoc process talking to stdout/stdin vs. systemd service listening on a TCP socket
• "JRE" or "native"
• DBUS protocol vs. JSON-RPC vs. command line arguments
• ...

Having survived signal-cli's README and Wiki and reviewed its various binary distributions and forks, one might end up with signal-cli as a local systemd service running under a dedicated UNIX account somewhere, a high degree of uncertainty on whether that was actually necessary, and a desire to get an actual terminal client running.

At this point, scli's README doesn't actually shed a lot of light on how it is designed to talk to signal-cli. Looking at the source, it seems to be running a separate process using Python's subprocess. The README.md mentions having signal-cli "somewhere in the path" but doesn't really elaborate more than that (and even this is under the "manual install" section).

It would be helpful if the README at least answered the following:

• Does scli always execute its own signal-cli subprocess, or can it talk to an existing signal-cli server (if so, using what protocols)?
• Does it require a DBUS service running in the background, or just some libraries installed?
• Should one use the "-jre" or "-native" version, or does that matter?

I'm more than happy to submit a patch to README.md if/when I get scli itself working (re https://github.com/isamert/scli/issues/206 ) and have a better idea of how it works myself.

[exquo]

scli reads JSON output from the signal-cli daemon's stdout. scli sends commands to signal-cli through its dbus interface. Signal-cli's JSON-RPC and socket interfaces had not yet been added when scli implemented communications with the signal-cli daemon.

Setting up signal-cli might indeed seem overwhelming when looking at the documentation for the first time. However, for most systems, a binary from its Releases page should just work without additional manual intervention.

• Does scli always execute its own signal-cli subprocess, or can it talk to an existing signal-cli server (if so, using what protocols)?

Scli always starts signal-cli daemon in a new process and attaches to (i.e. reads from) its stdout, as you have correctly observed from the source code. It does not talk to an already running instance of a signal-cli daemon.

• Does it require a DBUS service running in the background, or just some libraries installed?

Signal-cli daemon, started by scli, will register a DBUS service. So, the functioning dbus system is necessary. Typical desktop *nix systems have dbus running out of the box, and no special setup should be needed.

• Should one use the "-jre" or "-native" version, or does that matter?

Either one should work, although the native version might be less reliable in general (some functionality might be missing).

So, scli should not normally require any additional setup after having a functional signal-cli executable in the system path.

[exquo]

Those are valid questions, but knowing the answers to them shouldn't be necessary to use scli (which is the main goal of the instructions in the README).

There is indeed a lot of information available in signal-cli's docs, and there are many different ways to install and use it. But for the purposes of using scli, it should be as simple as the README has it: place signal-cli's executable (either "-jre" or "-native") somewhere on the $PATH, and have a working dbus setup. No need to launch signal-cli (in any mode) manually by the user; and if there's already a signal-cli process running, scli will complain.