Re: KIP-658 Deprecate all setters of Headers

2020-09-11 Thread Matthias J. Sax
Well, I am not totally sure if immutability is actually desired for `Headers`? Consider the case when there is an application that just wants to add for example a tracing header field. It would just call `add()` on the consumer record's headers and pass the modified `Headers` object to the

Re: KIP-658 Deprecate all setters of Headers

2020-08-18 Thread Chia-Ping Tsai
> If you create a new `ProducerRecord` you would not pass in a `Headers` > object but a `Iterable`? > > And for `ConsumerRecord` you just get a `Headers` object back and don't > need to worry about the concrete implementation? You are right. I'd give a bad case :( For another reason, could we

Re: KIP-658 Deprecate all setters of Headers

2020-08-18 Thread Matthias J. Sax
Thanks for the KIP. However, I am not sure for what use-case you would need to implement the `Headers` interface? If you create a new `ProducerRecord` you would not pass in a `Headers` object but a `Iterable`? And for `ConsumerRecord` you just get a `Headers` object back and don't need to worry

KIP-658 Deprecate all setters of Headers

2020-08-18 Thread Chia-Ping Tsai
Hi everyone, I would like to start a discussion on KIP-658: https://cwiki.apache.org/confluence/x/-DJ4CQ KIP-658 plans to deprecate all setters of Headers and provide default implementation. The benefit of this KIP are shown below. 1. Users don't need to implement those setters which are not