Thanks Jorge, overall looks good to me. Maybe we can clarify a bit in the wiki that the reason we have to not include the additional `final String... stateStoreNames` params in the new `process` API is that we need to have overloaded functions which takes `ProcessorSupplier<...> ` where the output types are not `Void`, but due to type eraser we cannot distinguish the new overloaded function signatures with the old ones if they also include `final String... stateStoreNames`. And in javadocs explains that if users want to connect state stores to this processor, they could use the `connectState` API instead.
Otherwise, I'm +1. Guozhang On Tue, Feb 15, 2022 at 11:54 AM John Roesler <vvcep...@apache.org> wrote: > Thanks, Jorge! > > I'm +1 (binding) > > -John > > On Tue, 2022-02-15 at 19:16 +0000, Jorge Esteban Quilcate > Otoya wrote: > > Hi all, > > > > I'd like to start a vote on KIP-820 which proposes extending KStream to > use > > the new Processor API > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API > > > > Thanks, > > Jorge > > -- -- Guozhang
