[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