Thanks Kenn, this is super helpful.
On Mon, 21 Dec 2020 at 09:57, Kenneth Knowles <k...@apache.org> wrote: > For the capability matrix, part of the problem is that the rows don't all > make that much sense, as we've discussed a couple times. > > But assuming we keep the content identical, maybe we could just have the > collapsed view and make the table selectable where *just* the selected cell > controls content below? You won't be able to do side-by-side comparisons of > the full text of things, but you will be able to keep the overview and > drill in one at a time quickly. Just one idea. > > A couple ways to save space without rearchitecting it: > > - Apache Hadoop MapReduce and JStorm can be removed as they are on > branches, not released. > - I think we can also remove rows that are not started or not complete in > the Beam Model, and remove the Beam Model column. > - I think Splittable DoFn really just deserves one row for bounded, one > for unbounded, and any caveats go in the details. > - All the windowing rows can be condensed into "Basic windowing support" > and "Merging windowing support" and any runner that can only run a couple > WindowFns can have details in the caveats. At this point any runner that > doesn't do Windowing by invoking a user's WindowFn simply doesn't really > support windowing in the model. > - "Configurable triggering" can absorb "Event-time triggers", > "Processing-time triggers", "Count triggers", and "Composite triggers". > Same. At this point any runner that doesn't support the whole triggering > language doesn't really support triggers fully. > > Kenn > > On Mon, Dec 14, 2020 at 7:39 PM Griselda Cuevas <g...@apache.org> wrote: > >> Hi folks, another page that's getting a refresh this time around is the >> Capability Matrix, which is one of the most critical pages for users as >> they evaluate the current support for each of the Beam runners. >> >> The situation we'd like to get your input on is: How do we optimize the >> expanded version of the capability matrix, which explains the level of >> support in each of the functions? >> >> Right now the text gets in the way of analyzing the table and makes >> reading hard. You can see a screenshot in the Beam wiki here [1], the file >> is titled current_CapMatExt. >> >> One of the proposed solutions is that after clicking the link "(click to >> expand details)", we load a new page that has the corresponding table to >> the click (what, where, when, how) at the top, and all the content of each >> runner/function gets displayed at the bottom of the page, the file with the >> proposed design is also in the Beam wiki here [1] and the file's name is >> proposed_CapMatExt. This solution isn't perfect either, since we'd need to >> move too much text under the table and reading isn't much easier. >> >> Do you have suggestions/ideas in how to condense the extended version? >> >> Share with us your feedback through this week, >> Thanks! >> G >> >> >> [1] >> https://cwiki.apache.org/confluence/display/BEAM/Website+Redesign+Files >> >
