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
> 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
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
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