could be implemented via clj-opencpu and rincanter in the same way.
Now lets assume, that we want to call this:
seq(a,10)
(so "a" is taken from the environment).
Even though it is syntactically possible to do such a call with OpenCPU
(call-R-function a-context "base" "seq" {:from "a" :to 10}) ;quotes around a get removed
=> "object 'a' not found\n\nIn call:\nseq(from = a, to = 10)\n"
it can never work, as all calls to OpenCPU work in isolation. (so in an empty environment).
It is not possible to "set variables" before doing a call. (what is possible is to "reuse" results from previous calls via the session API). But this would work like this:
So the session id of the result of the first call can be passed as a parameter to the second.
The rincanter implementation might get this example working (if the variable was set somehow before)
So a opencpu backed implementation of the R protocol can never call successfully (in no circumstances), an R function call like "seq(a,10)" while a rincanter backed can make it work "under condition that "a" was defined before").
This is a big problem for a common interface, right ?
There is a fundamental difference between OpenCPU and rincater/jvmr.
OpenCPU is stateless. Each call to the OpenCPU executes in an "empty" R environment.
This makes it very hard to define common behavior via the protocol. Lets take some examples:
lets assume we want to execute a function in R:
I could see how the call to the R protocol as I defined here usecase.md
could be implemented via clj-opencpu and rincanter in the same way.
Now lets assume, that we want to call this:
(so "a" is taken from the environment). Even though it is syntactically possible to do such a call with OpenCPU
it can never work, as all calls to OpenCPU work in isolation. (so in an empty environment). It is not possible to "set variables" before doing a call. (what is possible is to "reuse" results from previous calls via the session API). But this would work like this:
So the session id of the result of the first call can be passed as a parameter to the second.
The rincanter implementation might get this example working (if the variable was set somehow before)
So a opencpu backed implementation of the R protocol can never call successfully (in no circumstances), an R function call like "seq(a,10)" while a rincanter backed can make it work "under condition that "a" was defined before").
This is a big problem for a common interface, right ?
Any comment ?