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.
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
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
I’m currently having trouble building the project.
I think it’s because json-schema.org either has gone offline or is borked up in
DNS.
Hopefully this is transient - but in any case I’ve opened STREAMS-459 for us to
figure out how we think situations of this nature should be handled.
Steve
Hello ComDev,
The Streams podling has been brainstorming ways to increase awareness of the
project and it’s capabilities. We’ve also been working to make it easier to
get started as a user, without starting the journey by downloading JDK Maven
and friends. Using the software to provide
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
