Re: [science-iwg] java <-> python service bridge

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

I am pretty sure that the Science projects would want to see this code
(Py4J and related tech) be full citizens of Eclipse so that the
Science projects can then depend on them. So that limits Py4J to exist
within EF.

Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 18 July 2016 at 23:48, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
> Hi Christian,
>
> On 7/18/2016 11:57 AM, Christian Pontesegger wrote:
>>
>> Hi Scott,
>>
>> this is an interesting idea you bring up here. For me the first question
>> would be "do we have to stick to Py4J"?.
>
>
> Answer:  No, not at all.
>
> Explanation:   At the service (top) level, this is simply using OSGi Remote
> Service Admin specification to hook up any two processes (one of them
> typically java+OSGi framework, but even this isn't actually required).
>
> Since ECF's RSA implementation has a 'pluggable distribution provider'
> approach (see [1] for diagram), it's straightforward to use Py4j to create a
> new distribution provider (that's what I've done here [2]).
>
> [1] http://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
> [2] https://github.com/ECF/Py4j-RemoteServicesProvider
>
> In short, if other languages were to be supported with the same approach
> (why not?) then they could do a similar thing.   Each one would need it's
> own distribution provider, but they could all operate in a similar manner as
> specified by RSA.
>
> But also:  for the science working group the use case of OSGi services
> between Java and Python (both ways)...and the benefits of dynamics, and the
> availability of Py4j...it seemed like a good way to go.
>
>
>> Maybe in a more general form this could be applicable to any script engine
>> hooked into EASE. Then it would be a clear candidate to push this into the
>> core framework.
>
>
> I would say that that general form is the OSGi RSA specification...as it
> does specify the syntax and contents of an 'Endpoint Description' which is
> used to communicate about services between processes.
>
>>
>> If it stays limited to the Py4J bridge then our modules repository could
>> provide a home for that functionality. I would love to hear Jonahs thoughts
>> about this topic. This topic would also need a maintainer and tester. Would
>> you step up for that?
>
>
> My $0.03:   the RSA impl upon which this is based belongs in ECF (where it
> is now).   It's the distribution provider[2] that's a question.   That
> provider depends upon Py4j libs for both the Java side and Python side, and
> it depends upon the ECF RSA impl (on java side).  Given this, I think the
> first question is location, licensing and distribution for Py4j...as I'm
> pretty flexible about where [2] ends up, who maintains it, and how it's
> licensed. Further, there's a chance I can/would offer to support it as a
> committer on EASE or January if some means of supporting that could be
> found.
>
> Scott
>
>
> _______________________________________________
> science-iwg mailing list
> science-iwg@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/science-iwg