Roadmap 3.x

[albertosantini]

Please, comment this issue about RFP (Request for Proposal) for rio 3.x.

rio 2.x is solid and its interface, with callbacks and promises, fulfils the main use cases.

I would like to explore other use cases, improving devs and users experience.
Feel free to describe your use case.

This is a tentative list of the tasks:

• Add reactive approach - (main task)
• Add attrs implementation (see matrix example, example 10) - (optional change)
• Change node engine support from 0.10.x to the latest LTS 6.x - (internal change)
• Use ES2015 (optional internal change)
• Remove deps (binary, hexy) - (optional internal change)
• Use debug package vs. custom logging - (optional internal change).

Any comment, suggestion, contribution is welcome.

(Don't forget any implementation needs to work in Linux and Windows box).

[DanielReid]

I don't know much about the Windows version but perhaps the newer Rserve versions would allow this issue re: OOB communications to be fixed in the next version?

#11

[albertosantini]

@DanielReid Thanks for the feedback.

Well, on Windows, the Rserve release published doesn't support that feature.

Anyway I accept contributions about OOB communications.
I would glad to test them on Windows with respect to regressions.

[DanielReid]

OK, thanks! I was hoping that feature had made it in, but too bad. I'll have a look how hard adding OOB would be, but I won't have a lot of time soon.

[nospam2000]

my understanding is, that currently all parameters are passed as strings to Rserve. It would be nice to be able to pass double values in a binary encoded way. This should be better for precision, performance, memory usage and robustness.
It would be also nice to support the commands RServe CMD_setSEXP and CMD_assignSEXP.

[albertosantini]

@nospam2000

CMD_eval is battle-tested in different flavors of Rserve adapters.

For an untyped language like JavaScript, it is not Java or C++, it doesn't make sense adding complexity for boxing and unboxing variables.

Another approach would be using native bindings, but it is exactly the aim of this project, avoiding native bindings: in this case, you have precision, performance, memory usage and robustness of js realm. :)

Anyway contributing is welcome.

[KillariDev]

I would have a need to be able to keep connection open instead of creating a new R environment every time. At the moment my code needs to load the whole data from disk to memory in every call and only then perform computations on it. It would be handy to be able to load the data once to rserves memory and then perform fast queries into it. Is this something that could be implemented in 3.x?

[albertosantini]

@kimiylilammi thanks for the feedback.

I think that it is feasible.

See https://stackoverflow.com/questions/15314880/how-to-connect-to-rserve-with-an-r-client

Also you can use eval and/or source directives in the Rserve configuration file (or corresponding start-up arguments) to run any code before the Rserve server starts up. Any packages you load that way will be pre-loaded for all subsequent connections.