I like it. Having the extra portability layer really opens up these possibilities that wouldn't make a usable API for a user, but are really helpful for modeling.
I've only got View permissions to the doc, so commenting here. You mention that they are modeled as a PCollection, but it seems that they will re-use the PCollection protos and data plane but there's no sense in which a runner can just treat this as a PCollection. It will have to be noticed (by coder?) and special-cased. And will you be removing the specs from the ParDoPayload? Kenn On Mon, Jun 4, 2018 at 3:00 PM Lukasz Cwik <lc...@google.com> wrote: > I have been working on a proposal for adding support for timers to the > Apache Beam portability APIs. > > The synopsis is to model timers as PCollections. This allows us to treat > timers as just another type of data that is transmitted/received by a > Runner during execution and leverage all the work that went into those APIs > and implementations. > > For further details, please take a look this doc[1]. > > 1: https://s.apache.org/beam-portability-timers >
