Thanks for the update, Jorge! I’m still +1 (binding)
Thanks, John On Thu, Feb 17, 2022, at 12:57, Guozhang Wang wrote: > 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
