-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to signal-cli's JSON-RPC interface? #103
Comments
I've thought about incorporating this change into scli, but couldn't think of what problem that would solve. Since scli is a single-user application, it has to know which account to use. If there is only one registered account in the signal-cli data folder, scli already automatically selects it (does not require the Do you mean scli could be made into a multi-account application (i.e. send and receive messages for all registered signal-cli accounts)? Or just
Scli reads signal-cli output from a signal-cli process' stdout. That's not the only way to get signal-cli's messages: we could alternatively listen to messages signal-cli sends through dbus. But that's how it's currently done, we start a new signal-cli subprocess and attach a pipe to its stdout. I can see a use-case here: if you have multiple accounts and want to use one of them with scli while using others with other programs. Is that along the lines you were thinking? |
Yes, exactly this scenario (I can see my first post was a bit vague). I don't mean for scli to be multi-account. Instead, support for communication with signal-cli over dbus would be enough. |
Gotcha. There might be some advantages in listening to dbus output rather then using stdout, but a big disadvantage is that signal-cli's dbus interface's features often lag behind the stdout interface. If there are other considerations (either pro or against), please leave a comment. For using scli with one account among several run by signal-cli daemon, you can specify the username with |
I don't know about the past, but a least lately, signal-cli's dbus interface has been receiving first-class support and attention, if not having more features now implemented than the plain CLI interface. Some additional benefits for listening on the dbus interface:
What are your thoughts about these? |
Signal-cli has a newer JSON-RPC API with the most comprehensive functionality. The dbus interface "will likely always lag behind". JSON-RPC would be the best choice for scli, but switching to it now will require quite a bit of a code rewrite. We might do it at some point in the future, though. |
Multiple accounts are now supported via signal-cli dbus daemon by not specifying the
-u
parameter with thedaemon
option:AsamK/signal-cli@ca86c42
In this case, the data directory is scanned for registered accounts and a new dbus endpoint is created for each one.
It would be nice if scli would support this, and perhaps best if scli checks to see whether a signal-cli dbus daemon has already started before trying to open it directly using
Popen
.The text was updated successfully, but these errors were encountered: