Github user elbamos commented on the pull request:
https://github.com/apache/incubator-zeppelin/pull/208#issuecomment-156768636
@Leemoonsoo
Please let me know who from the PPMC I can work with to resolve the
continuing problems with the travis build and zeppelin-spark architecture.
Regarding your comments, as I've explained in our e-mail exchange:
##### 1. Scala-R invocation
I am not using rscala.
It is not possible to use the SparkR connection in the way you describe. I
did look into this early on. There are numerous packages for interfacing the
jvm and R. None of them use two-way connections.
The python-spark and zeppelin integrations you describe leverage an
external dependency. There is no comparable package available for R that has a
compatible license.
##### 2. Knitr*
As I understand, you don't use R, so it may seem strange to have a separate
interpreter rather than a function. That's understandable.
The distinction between the r-repl and knitr interpreters makes perfect
sense for people who are coming from R. The repl and knitr handle code, and
errors, and output, in fundamentally different ways.
They have different capabilities. It is not possible, consistent with the
zeppelin architecture, to put both capabilities into a single interpreter
without making the use of that interpreter very unintuitive for someone coming
from an R background.
The knit2html() command is something no R user would ever use when making
use of R. It is perhaps best thought of as part of the "R operating system."
##### 3, The author tag
That's really fine, but in my view this is the lowest-priority possible
item.
The highest priority is the travis build problems. Travis consistently
fails building parts *other* than rzeppelin.
The other high priority is consistency with the Zeppelin-Spark interface,
which has grown quite complex and difficult to use.
My users have had a long stream of issues getting Spark to work through
zeppelin. They get reported to me as rzeppelin issues, but have all turned out
to be issues in the way zeppelin and spark interface, e.g., with conflicts
between SPARK_HOME and spark.home. rzeppelin needs to be consistent with the
rest of the Zeppelin architecture in that regard. This is not something I can
fix because I don't own that code.
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
