Hello Jorge, Thanks for bringing this KIP! I think this is a nice idea to consider using a single overloaded function name for #process, just a couple quick questions after reading the proposal:
1) Does `ValueProcessorContext` have to be a public API? It seems to me that this can be completely abstracted away from user interfaces as an internal class, and we call the `setKey` before calling user-instantiated `process` function, and then in its overridden `forward` it can just check if the key changes or not. 2) Related to 1) above, in the past the rationale for enforcing it at the interface layer rather than do runtime checks is that it is more efficient. I'm not sure how much overhead it may incur to check if the key did not change: if it is just a reference equality check maybe it's okay. What's your take on this? Guozhang On Tue, Feb 8, 2022 at 5:17 AM Jorge Esteban Quilcate Otoya < quilcate.jo...@gmail.com> wrote: > Hi Dev team, > > I'd like to start a new discussion thread on Kafka Streams KIP-820: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API > > This KIP is aimed to extend the current `KStream#process` API to return > output values that could be chained across the topology, as well as > introducing a new `KStream#processValues` to use processor while validating > keys haven't change and repartition is not required. > > Looking forward to your feedback. > > Regards, > Jorge. > -- -- Guozhang
