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 

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.


Reply via email to