Thanks everyone for the detailed comments and discussions. It looks like by now, we mostly agree with the requirements and overall direction needed for the API, though there is continuing discussion on specific details. I want to highlight two new sections of the doc, which address some discussions that have come up:
- *Existing state and transactionality*: this section addresses how we will address an existing transactionality inconsistency in the existing Java API. ( https://docs.google.com/document/d/1GadEkAmtbJQjmqiqfSzGw3b66TKerm8tyn6TK4blAys/edit#heading=h.ofyl9jspiz3b ) - *State for merging windows*: this section addresses how we will deal with non-combinable state in conjunction with merging windows. ( https://docs.google.com/document/d/1GadEkAmtbJQjmqiqfSzGw3b66TKerm8tyn6TK4blAys/edit#heading=h.ctxkcgabtzpy ) Let me know any further comments and suggestions. On Tue, May 22, 2018 at 9:29 AM Kenneth Knowles <k...@google.com> wrote: > Nice. I know that Java users have found it helpful to have this > lower-level way of writing pipelines when the high-level primitives don't > quite have the tight control they are looking for. I hope it will be a big > draw for Python, too. > > (commenting on the doc) > > Kenn > > On Mon, May 21, 2018 at 5:15 PM Charles Chen <c...@google.com> wrote: > >> I want to share a proposal for adding user state and timer support to the >> Beam Python SDK and get the community's thoughts on how such an API should >> look: https://s.apache.org/beam-python-user-state-and-timers >> >> Let me know what you think and please add any comments and suggestions >> you may have. >> >> Best, >> Charles >> >
