Vscode communicate directly with R through http requests?

[danielbasso]

TL;DR: How about using the pumbler package to make vscode communicate directly with R through http requests?

(Maybe a follow up to #440)

#506 made me think about ways to enhance the current View() functionality. I think DataTables is fine, even if it's a bit old and based on JQuery; it just need to be better presented (match the theme colors, better formatting on columns, pagination, etc). The only feature I believe is missing, which for me is a big one, is the dynamic loading of the table rows, for big data frames.

DataTables, as well as other good table libraries, already has a solution for that: server-side processing, where all the library does is pass a set of parameters to the server, through Ajax http requests, which is responsible for performing all paging and filter processing.

This led me to seek to understand in more depth how vscode interacts with R. The current way, as far as I could understand, is that session.ts sources init.R in some kind of watcher fashion; vscode then will make requests through writing in request.log file; R will write the appropriate results back in other files inside /tmp/'myrsession' that will the read back by vscode.

This is a nice approach for what has been done so far, but I fear that it can became cumbersome for some tasks, like the server-side processing mentioned before.

Wouldn't be interesting to consider to start an actual http server to communicate with R? There is this package, pumbler that already does that in a simple fashion. Just select a port and you can create endpoints; this would allow direct communication between R and vscode through http. Javascript has an amazing support to http requests out of the box. I think that it not only would allow new possibilities, but it would make things easier to implement and maintain.

I would like to know from the more experienced contributors to the project if this is a real possibility or if there is a hard restriction to this idea, making me stick to the ways that things are done right now. I know introducing new dependencies to this extension is unwanted, but the tradeoff could be good.

[ElianHugh]

Given he wrote the session watcher, @renkun-ken is probably the best person for this consideration!

I think that we'd also have to consider that plumber would be a dependency of vscode-R, and whether that has any caveats

Edit: having said that, I think it's a neat idea and could also smooth liveshare support

[danielbasso]

Yeah, I know that adding dependencies is a bad idea and this isn't something very straightforward to implement as it seems. My underlying goal with this discussion was to fiddle with this topic and think in what ways we could, at least, mimic such functionality using the current implemented patterns.

My special interest is how DataTables could use it's native server side processing to achieve dynamic loading.

Other ideas that pop in my mind is adding server side filtering (with basically would let the user filter the data however it wants, using native R code) and inplace modifications (like remove/modify buttons for quick testing).

[MilesMcBain]

One of the things that is convenient about the current design is the way it works relatively seamlessly with the remote development scenario.

VSCode has the ability to work within the environments of docker containers or remote hosts over ssh, while maintaining the same desktop user experience. It's quite a drawcard feature for some people.

The file-based communication method is nice because it requires no additional access to the remote environment or container. If you can run a shell within the machine, you can develop against an R session running in that machine using our session watchers etc since file access comes by default.

If you want to communicate with a remote R process via tcp you'll need to be able to have a network layer route to a specific port on the machine. In the docker scenario this means forwarding extra ports on the container, and is probably not a big deal.

For the remote host dev over ssh scenario though this can be a deal breaker. Layers of security between you and the remote host may block the port or communications protocol you are trying to use. You may not have the power to change this easily, if at all.