Allow the R `.vsc.attach()` function to connect by TCP to VSCode - supporting remote R sessions
Currently, the only way to run R session that will be connected to VSCode by this extension, is to run a remote VSCode server on this machine, and then the R terminal/session is "local" in the sense it's running on the same machine running the VSCode server. This is due the following more general issue:
Currently, this extension connects to the R session via .vsc.attach(), and then VSCode and the R session communicates via temporary files.
While this solution makes the usage of the R plugin simple, it would be problematic in two scenarios:
- Connecting different R sessions on different VSCode backends - currently the attachment mechanism may conflict.
- Connecting to a remote R session - right now the only solution is to execute VSCode remote backend on the same remote machine.
A simple solution that wouldn't ruin the current mechanism is to support communicating with the VSCode instance in two channels - one by the file-system(currently), and the second is by listening to a TCP connection.
This way the R function will become .vsc.attach(port=NULL) and when the port isn't null, it will try to attach by the TCP port.
For the UI, the VSCode extension status-bar display could be changed to "R - (not attached, TCP:PORT_NUMBER)".
I think this is supposed to eventually get solved through the "webserver" option. The way it works now is that it picks a random port when the webserver starts. The relevant code is here: https://github.com/REditorSupport/vscode-R/blob/master/R/session/vsc.R#L133C9-L133C9
It should be easy to modify this code to bind to a specific port.
webserver
Thanks! But this server is in the other direction - a TCP(WebSocket) connection hosted by the R session itself, while I want a TCP connection hosted by VS code, and the one that connects to it is the R session by .vcs.listen(IP, PORT).
Additionally, even if somehow you'd say that VSCode would initiate the connection to the R session, currently it's not the way it is implemented. Currently, the "normal" connection is handle by files containing the request and the response, and for the additional features on the background of the R session, only then the VSCode starts the WebSocket connection.
Ah! That way you wouldn't necessarily need the vscode-server instance at all. Seems like this might also solve my issue #1391
This issue is stale because it has been open for 365 days with no activity.
Any update?