Sweet; that led me to:
https://beam.apache.org/contribute/runner-guide/#the-runner-api (which I
can't believe I missed).



On Tue, Jul 17, 2018 at 9:21 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Hi Austin,
>
> If your runner provide the gRPC portabality layer (allowing any SDK to
> "interact" with the runner), it will work no matter how the runner is
> implemented (JVM or not).
>
> However, it means that you will have to mimic the Runner API for the
> translation.
>
> Regards
> JB
>
> On 17/07/2018 18:19, Austin Bennett wrote:
> > Hi Beam Devs,
> >
> > I still don't quite understand:
> >
> > "Apache Beam provides a portable API layer for building sophisticated
> > data-parallel processing pipelines that may be executed across a
> > diversity of execution engines, or /runners/."
> >
> > (from https://beam.apache.org/documentation/runners/capability-matrix/)
> >
> > And specifically, close reading
> > of: https://beam.apache.org/contribute/portability/
> >
> > What if I'd like to implement a runner that is non-JVM?  Though would
> > leverage the Python and Go SDKs?  Specifically, thinking of:
> >  https://www.wallaroolabs.com (I am out in NY meeting with friends there
> > later this week, and wanted to get a sense of, feasibility, work
> > involved, etc -- to propose that we add a new Wallaroo runner).
> >
> > Is there a way to keep java out of the mix completely and still work
> > with Beam on a non JVM runner (seems maybe eventually, but what about
> > currently/near future)?
> >
> > Any input, thoughts, ideas, other pages or info to explore -- all
> > appreciated; thanks!
> > Austin
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Reply via email to