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-boun...@r-forge.wu-wien.ac.at [mailto:rcpp-devel-boun...@r-forge.wu-wien.ac.at] On Behalf Of Dirk Eddelbuettel Sent: Thursday, November 20, 2014 9:14 AM To: Christian Authmann Cc: rcpp-de...@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@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 | e...@debian.org _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
