+1. I think we should also better reflect connector capabilities (or
include them into features), to avoid surprises like [1].
[1]
https://lists.apache.org/thread.html/9e9270bfb85058e24b762790e948d8bfc558f58ef1df9e14c4e4464c@%3Cuser.beam.apache.org%3E
On Fri, Nov 8, 2019 at 10:51 AM Kenneth Knowl
On Fri, Nov 8, 2019 at 9:46 AM Brian Hulette wrote:
> > Does it make sense to do this?
> I think this makes a lot of sense. Plus it's a good opportunity to refresh
> the UX of [1].
>
+1 to total UX refresh. I will advertise
https://issues.apache.org/jira/browse/BEAM-2888 which has a lot of relat
On Fri, Nov 8, 2019 at 9:46 AM Brian Hulette wrote:
>
> > Does it make sense to do this?
> I think this makes a lot of sense. Plus it's a good opportunity to refresh
> the UX of [1].
>
> > what's a good way of doing it? Should we expand the existing Capability
> > Matrix to support SDKs as well?
> Does it make sense to do this?
I think this makes a lot of sense. Plus it's a good opportunity to refresh
the UX of [1].
> what's a good way of doing it? Should we expand the existing Capability
Matrix to support SDKs as well? Or should we have a new one?
To me there are two aspects to this: how
FWIW there are currently at least 2 instances of capability matrix [1] [2].
[1] has been in need of a refresh for a while.
[2] is more useful but only covers portable runners and is hard to find.
Thomas
[1] https://beam.apache.org/documentation/runners/capability-matrix/
[2] https://s.apache.or
Hi all,
I think this is a relatively common question:
- Can I do X with runner Y, and SDK Z?
The answers vary significantly between SDK and Runner pairs. This makes it
such that the current Capability Matrix falls somewhat short when potential
users / solutions architects / etc are trying to deci
