Hi all,
On my own previous statement: bq. Not that I mind doing it directly (I intend to use a Java client), but please be aware that a String binary representation is based on the charset encoding, while the Long binary representation varies according to the language. I went back to double check this, and it seems that parsing the binary directly to long is already done (e.g.: the 'timestamp' header), so I guess this is OK and I was simply over-engineering it.The KIP is now adapted to use long directly. On Guozhang's statement: bq. I'm also in favor of making the `timestamp` a preserved config value along with `offset`, for which we would not go into the headers to look for the matching key, but directly look into the timestamp field of the message. In reviewing the previous point I think I understood this a bit better, in that you mean using the already existing 'timestamp' field, which the client can customize, in order to determine the version of the record.Would you then be OK with the client hijacking this when/if they need to use incremental versioning instead? There are some KIP's opened regarding this field, and this field itself is already used for other things, so it already has some meanings attached to it. I personally prefer to avoid attaching multiple meanings to a single field, but if it allows for this feature to go through, then I am OK with it.Please let me know your thoughts here. Cheers!
