[Rcpp-devel] Review request: Sandboxed R integration via RInside
Smith, Dale (Norcross)
Dale.Smith at Fiserv.com
Thu Nov 20 15:28:18 CET 2014
I've always had licensing concerns with RInside. I preferred Rserve and it worked well for our purposes years ago.
This new code sounds like it is more flexible than Rserve and deserves to be a separate package, not in RInside. But that's a personal preference to avoid the *appearance* of licensing concerns.
Dale Smith, Ph.D.
Senior Financial Quantitative Analyst
Financial & Risk Management Solutions
Fiserv
Office: 678-375-5315
www.fiserv.com
FORTUNE® Magazine's 2014 World's Most Admired Companies
Facebook: Like Fiserv · Twitter: Follow @Fiserv · LinkedIn: Connect Fiserv . Careers: Join Fiserv
Fiserv What's Next NowSM Campaign
-----Original Message-----
From: rcpp-devel-bounces at r-forge.wu-wien.ac.at [mailto:rcpp-devel-bounces at r-forge.wu-wien.ac.at] On Behalf Of Dirk Eddelbuettel
Sent: Thursday, November 20, 2014 9:14 AM
To: Christian Authmann
Cc: rcpp-devel at r-forge.wu-wien.ac.at
Subject: Re: [Rcpp-devel] Review request: Sandboxed R integration via RInside
On 20 November 2014 at 14:58, Christian Authmann wrote:
| Hello,
|
| I've developed a solution to integrate R into an application in a
| safer way than the direct integration provided by RInside. It is
| conceptually similar to RServe: the application does not link to R,
| but communicates with a different process where R is running. Securing
| the separate process is much easier.
|
| Unlike RServe, my solution has the full power of Rcpp/RInside: one can
| communicate custom data types, and one can even allow the R code to
| call back into provided C++ functions.
|
| I've made a pull request, but the code is complex enough to need a few
| more eyes before merging. Please read and comment, either on github or
| via email!
Given that I saw it first via the pull request, I started commented at the pull request and wrote (after two more edits):
About to leave town for a few days of workshopping so may not get to it "soon".
Couple of really quick first comments:
* Keeping it in examples/ is a good idea, it won't break anything
* On the other hand, "nobody sees it" that way. Just for argument's sake,
should it be a separate project? "RProccessInside" or "RInside2" or
something? Or move up into RInside?
* All my code (or at least the code that matters) is GPL-2. If you stick
it in here, I am not sure your BSD headers matter. It may just became
GPL-2 as the whole aggregate does anyway as all of R, Rcpp and RInside
are GPL-2 so why not make matters simpler and convert this to GPL-2 as
well?
All that said, I do of course love a nice and well put-together pull
request. And as it does not harm, I'm happy to take it. I was just
wondering how to best give it more exposure...
We can keep the discussion "here" or "there" -- whatever works best. Maybe "conceptual" comments here and code nitpicking on GH?
RInside "plus forking a la RServe plus process separation" is a potentially rather useful idea. Nice work!
Dirk
| If you cannot comment on the code, but think this could be useful for
| you, please let me know.
|
| https://github.com/eddelbuettel/rinside/pull/8
|
|
| Thanks!
| Christian
| --
| Christian Authmann
| Philipps-Universität Marburg
| Fachbereich Mathematik und Informatik
| AG Datenbanksysteme
| Hans-Meerwein-Straße
| D-35032 Marburg
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-deve
| l
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org _______________________________________________
Rcpp-devel mailing list
Rcpp-devel at lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
More information about the Rcpp-devel
mailing list