+1 for 2 if 3 is not a crowd, I would like to help. On Wed, Nov 4, 2015 at 10:12 AM Pramod Immaneni <pra...@datatorrent.com> wrote:
> 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. > > > > > > > > > >
