THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Adds the ability for producers to set standard header key=value value pairs
- No incompatible client api change (only new methods)
- Allows users to specify the serialisation of the header value per header
- Provides a standardised interface to eco systems of tools that then can grow around the feature
The disadvantage of this proposal is:
- Change to the message object
Key duplication and ordering
- Duplicate headers with the same key must be supported.
- The order of headers must be retained throughout a record's end-to-end lifetime: from producer to consumer.
Create a Headers Interface and Implementation to encapsulate headers protocol.
- See above public interfaces section for sample interfaces.
Add a headers field Headers to both ProducerRecord and ConsumerRecord
- Accessor methods of Headers headers() added to interface of the ProducerRecord/ConsumerRecord.
- Add constructor(s) of Producer/ConsumerRecord to allow passing in of an existing/pre-constructed headers via Iterable<Header>
- use case is MirrorMakers able to copy headers.
Add new method to make headers accessible during de/serialization
- Add new default method to Serialization/Deserialzation class, with Header parameter
- Due to KIP-118 not being implemented, a new extended interface ExtendedSerializer ExtendedDeserializer with new extra methods is introduced instead
- Existing De/Serialization will be wrapped and work as before.
- Due to KIP-118 not being implemented, a new extended interface ExtendedSerializer ExtendedDeserializer with new extra methods is introduced instead
...