Re: [DISCUSS] Beam

2016-11-23 Thread Suneel Marthi
+1 to exploring Reactive Streams On Wed, Nov 23, 2016 at 12:25 PM, Timothy Spann wrote: > Reactive Streams is very cool, but only used by a few frameworks. > > https://en.wikipedia.org/wiki/Reactive_Streams > > Its adoption is slow, but starting to grow. I’ve worked

Re: [DISCUSS] Beam

2016-11-23 Thread Trevor Grant
Apache family. Specifically to avoid issues like the json thing in the other thread. On Nov 23, 2016 12:40 PM, "Suneel Marthi" wrote: > "keeping it in the family" - explain Family here? > > On Wed, Nov 23, 2016 at 1:29 PM, Trevor Grant > wrote: > >

Re: [DISCUSS] Beam

2016-11-23 Thread Suneel Marthi
"keeping it in the family" - explain Family here? On Wed, Nov 23, 2016 at 1:29 PM, Trevor Grant wrote: > Knowing nothing about Reactive streams, and already voicing my opinions > about beam on this thread, I'd rather see Apache Beam be used if for no > other reason

Re: [DISCUSS] Beam

2016-11-23 Thread Trevor Grant
Knowing nothing about Reactive streams, and already voicing my opinions about beam on this thread, I'd rather see Apache Beam be used if for no other reason than "keeping it in the family", e.g. less worry about managing dependency licenses, etc, etc. Tg Resident neigh-sayer of the thread On Nov

Re: [DISCUSS] Beam

2016-11-23 Thread Timothy Spann
Reactive Streams is very cool, but only used by a few frameworks. https://en.wikipedia.org/wiki/Reactive_Streams Its adoption is slow, but starting to grow. I’ve worked with RxJava and Project Reactor. Once Spring 5 is out for a bit, then it will probably time to look at the Reactive

Re: [DISCUSS] Beam

2016-11-23 Thread Matt Franklin
On Mon, Nov 21, 2016 at 6:27 PM Joey Frazee wrote: > I'm in favor of this for a few reasons: > > - There are enough stream processing frameworks out there that it makes it > hard for us to offer much on that front. I don't think streams fills a gap > for this internally

Re: [DISCUSS] Beam

2016-11-23 Thread sblackmon
Opened: STREAMS-460: Proof-of-concept: package and test streams processor with beam APIs / local runner (https://issues.apache.org/jira/browse/STREAMS-460) STREAMS-461: Proof-of-concept: package and test streams provider with beam APIs / local runner

Re: [DISCUSS] Beam

2016-11-21 Thread Joey Frazee
I'm in favor of this for a few reasons: - There are enough stream processing frameworks out there that it makes it hard for us to offer much on that front. I don't think streams fills a gap for this internally so we have more to contribute in creating something that people can use with Beam.

Re: [DISCUSS] Beam

2016-11-21 Thread sblackmon
  On November 21, 2016 at 2:19:11 PM, Suneel Marthi (suneel.mar...@gmail.com(mailto:suneel.mar...@gmail.com)) wrote:  > I agree too, I have been playing with Beam for a few months now without a > runner and the API is still immature, but nevertheless keep it on the radar > since its gonna

Re: [DISCUSS] Beam

2016-11-21 Thread Suneel Marthi
I agree too, I have been playing with Beam for a few months now without a runner and the API is still immature, but nevertheless keep it on the radar since its gonna be a TLP soon. >From Streams perspective, how do we see the project using Beam (similar to Spark/flink now); if so we can

[DISCUSS] Beam

2016-11-21 Thread sblackmon
Beam appears to be on it’s way to being the de-facto standard for data pipelines. I’d like to start a real discussion about whether and how to align streams interfaces with Beam interfaces. To pose a straw-man theory for discussion: Hypothesis: Streams would benefit by replacing the