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é <[email protected]> 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é > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
