I actually was thinking about an idea similar to option C before this topic came up. 208 is Knitr friendly, so r.r and r.knitr as a clear differentiator between the 702 spark.r interpreter makes sense to me.
B also looks like an decent option as well, but my preference is C. On 4/5/16, 11:18 AM, "Leemoonsoo" <g...@git.apache.org> wrote: >Github user Leemoonsoo commented on the pull request: > > > https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501 > > > Regarding, name conflict, i can come up with some options. > > a. Keep the same name 'spark.r' for both > [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java) > and > [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java). > And let user select it in build time using maven profile, -Pr for RRepl, > -Psparkr for SparkRInterpreter, or select it in a runtime using > `zeppelin.interpreters` property in conf/zeppelin-site.xml > > b. Change SparkRInterpreter name to 'spark.sparkr', similar to > PySparkInterpreter uses the name 'spark.pyspark' > > c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', > r.knitr'. > And make RRepl and KnitR more like generic R support rather than SparkR > support. Similar to what > [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying to > do for python > > > Personally, i'm good with all three options and prefer c) as a long term > plan, while my guess is many R users will use r without sparkr integration. > > What do you think? > > >--- >If your project is set up for it, you can reply to this email and have your >reply appear on GitHub as well. If your project does not have this feature >enabled and wishes so, or if the feature is enabled but not working, please >contact infrastructure at infrastruct...@apache.org or file a JIRA ticket >with INFRA. >---
