I would like to help. I might be able to pick up some of the smaller tasks.
On Wed, Nov 4, 2015 at 10:05 AM, David Yan <da...@datatorrent.com> wrote: > Thank you for all your feedback. Looks like option #2 wins. > > I will be working on this in November and please let me know if you'd like > to join the effort! > > On Wed, Nov 4, 2015 at 9:58 AM, Thomas Weise <tho...@datatorrent.com> > wrote: > > > Agreed, there is no ambiguity. > > > > #2 will also allow the user to tune locality as there are no implicit > > streams as opposed to the unifier like approach. > > > > On Wed, Nov 4, 2015 at 9:54 AM, David Yan <da...@datatorrent.com> wrote: > > > > > On Tue, Nov 3, 2015 at 9:57 PM, Thomas Weise <tho...@datatorrent.com> > > > wrote: > > > > > > > > > > > #2 will address that. But if an operator with the delay interface has > > > > multiple input ports, on which port will the engine perform the > delay? > > > > Maybe we will need to validate that a delay operator can only have a > > > single > > > > input port? > > > > > > > > > > My understanding is that the engine performs the +1 delay on the input > > > ports of operators that are connected to output ports of delay > operators. > > > So whether or not the delay operator has multiple input ports should > not > > > matter. > > > > > >
