> 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 we model the data, and how we present the data. For modelling the data: Do we need to maintain the full 3-dimensional <feature - SDK - runner> matrix? That seems untenable to me. With portability, I think the runner and SDK matrix should be completely independent, so it should be safe to just maintain <feature - SDK>, and <feature - runner> matrices and model the 3-dimensional matrix as the cross-product of the two. Maybe we should have a new capability matrix just for portable runners so we can exploit this property? For presenting the data: I think there would be value in just presenting <feature - runner> (basically what we have now in [1]), and also presenting <feature - SDK> separately. The <feature - SDK> display could serve as documentation too, with examples of how to do Y in each SDK. Maybe there would also be value in presenting <feature - SDK - runner> in some fancy UI so an architect can quickly answer "what can I do with SDK Z on Runner X", but I'm not sure what that would look like. [1] https://beam.apache.org/documentation/runners/capability-matrix/ On Thu, Nov 7, 2019 at 10:09 PM Thomas Weise <[email protected]> wrote: > 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.org/apache-beam-portability-support-table > > On Thu, Nov 7, 2019 at 7:52 PM Pablo Estrada <[email protected]> wrote: > >> 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 decide to adopt >> Beam, and which Runner / SDK to use. >> >> I think we need to put some effort in building a capability matrix that >> expresses this information - and maintain it updated. >> >> I would like to discuss a few things: >> - Does it make sense to do this? >> - If it does, 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? >> - Any other thoughts you may have about the idea. >> >> Best >> -P. >> >
