Well-defined API for interaction between R and a notebook about rcloud HOT 4 CLOSED

Does this keep the behavior of returning a special value (a uuid) which gets replaced?

Do we need to design in other interactive features at the same time, e.g.

• callbacks when something is clicked on (if there is anything special about that)
• a way for an R program to query the selection or filters
• a way to link diagrams between cells (again, if any special handling is needed for this)
• more generally, variables in R that represent JavaScript objects, and vice versa. (Yes I know, getting kind of wacky, just thought I'd throw it out there.)

Or are these separate concerns? I.e. is this ticket just about a modular plug-in design for javascript libraries, or should we also address the interactive features we want at the same time?

from rcloud.

Does this keep the behavior of returning a special value (a uuid) which gets replaced?

For now, it will be easier to keep the uuid-passing kludge, because it forces knitr to actually create a div which we can populate appropriate.

I.e. is this ticket just about a modular plug-in design for javascript libraries, or should we also address the interactive features we want at the same time?

I'd like to understand the design space a bit better before deciding if I want to hardcode these features, but let's say they're all up for discussion now. My original idea was to build the entire infrastructure on top of the two basic "RPC" primitives above:

• Javascript calling R: an asynchronous call that passes a list of values to some R closure. The call would look exactly like the calls on htdocs/js/rcloud.js: parameters and a continuation k. This would look idiomatic in the world of async javascript calls everywhere, so there should be no additional impedance mismatch.
• R calling Javascript: a blocking call that waits for a result from the Javascript side, likely implemented on top of the OOB message functionality of RServe. Again, this would look idiomatic in the R world, so no complications in the way R code would be structured should arise. There is a problem in the Javascript side, which is there's no way to enforce at the language level that some result will actually be sent back to R, and so it might become too easy to write buggy code that locks the R evaluator.

Ideally, the interactive features you describe above would be written using these two basic primitives, and exposed in rcloud.support and htdocs/js/rcloud.js respectively, so RCloud package writers could use the API on both sides of the system.

Your "way for an R program to query the selection or filters" list item is certainly the kind of thing we want to allow, but I'd like to design the primitives that RCloud package writers could use, rather than figure out the universe of all such possible requests.

from rcloud.

Here's partial progress for Javascript calling R, using the new support for object capabilities in rserve and rserve-js. Look at the code in basic.js and in oc.init.R.

I'm really happy with how clean the code looks. It's still callback pyramids, but there's nothing we can do specifically about that. The cool part is how ocaps on the R side transparently become async calls on the Javascript side.

from rcloud.

Since commit 4ae113c, this is enabled. See password.R for a trivial example of R+Javascript interaction that can be moved entirely into a library. Lots of cleaning up left to do on the source tree yet, but closing the issue for now.

from rcloud.