[
https://issues.apache.org/jira/browse/SPARK-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429858#comment-15429858
]
Shivaram Venkataraman commented on SPARK-16581:
-----------------------------------------------
These are good points -- The way I see it is that its a question what are the
various levels at which we present APIs to package developers. You are right
that the contract we have with the R->JVM API is that the run functions on the
JVM running Spark. If we are going to enable multiple JVMs (or say multiple
Spark contexts) then we will have to add some way to resolve which JVM to run.
That might change the implementation but should not affect the API
significantly I'd say (it would be something like passing a JVM id in the API).
The second question is about whether we want to expose the more internal
RBackend as a public API -- This is something we will have to discuss
separately and I am not sure we are ready to make such an RPC API public yet.
The remote backend change is still assuming the client and the server can
change hand-in-hand. Making RBackend public will mean that the server side API
is fixed.
> Making JVM backend calling functions public
> -------------------------------------------
>
> Key: SPARK-16581
> URL: https://issues.apache.org/jira/browse/SPARK-16581
> Project: Spark
> Issue Type: Sub-task
> Components: SparkR
> Reporter: Shivaram Venkataraman
>
> As described in the design doc in SPARK-15799, to help packages that need to
> call into the JVM, it will be good to expose some of the R -> JVM functions
> we have.
> As a part of this we could also rename, reformat the functions to make them
> more user friendly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
