Re: [PROPOSAL] Additional design for the Beam Python State and Timers API

2018-11-05 Thread Robert Bradshaw
On Fri, Oct 26, 2018 at 6:47 PM Kenneth Knowles wrote: > > It all sounds very useful but I have basic concerns about item 1. The doc > doesn't really seem to go into the design concerns that I have in mind. > > - map / flatMap are universal functions with definitions that we don't own > and

Re: [PROPOSAL] Additional design for the Beam Python State and Timers API

2018-10-30 Thread Kenneth Knowles
Yea, I would expect A. B would be ill-defined for processing time timers, and trouble for event time timers once we decouple firing time and effective timestamp. C could easily be very confusing; generally automatic window assignment outside the Window transform is weird. The timestamp has to be <

Re: [PROPOSAL] Additional design for the Beam Python State and Timers API

2018-10-30 Thread Lukasz Cwik
My concerns are around item 4 (left the same comments in the doc). What window should timers be using when looking up a side input? A) The window corresponding to the element that set the original timer. B) The window that would have been assigned based upon when the timer is scheduled to fire.

Re: [PROPOSAL] Additional design for the Beam Python State and Timers API

2018-10-26 Thread Kenneth Knowles
It all sounds very useful but I have basic concerns about item 1. The doc doesn't really seem to go into the design concerns that I have in mind. - map / flatMap are universal functions with definitions that we don't own and shouldn't violate - corollary: map / flatMap have per element