Hi guys, what's the rational behind PushbackSideInputDoFnRunner?
Why not using a DoFnRunner<WindowedValue<InputT>, OutputT>? It is the same thing I think, better represents what it does (most is delegated in general) and avoids yet another API which is not even implemented completely in 1 of the 2 implementation cause the interface is not relevant for one case (onTimer in ProcessFnRunner). Worse case we keep the pushbacksideinputdofnrunner interface but extends the dofn one to avoid to define other methods and we just break the process method name which is the only one which was not copied (not sure why). Personally I'd be to drop completely the interface but aliasing the first one with a default method to bridge the process methods sounds good as well and allows to reduce the forked code between both branches. wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
