This is shaping up good. A couple of higher-level comments:
- I think the overall goal for this and HBASE-8693 is to come up with a spec and implementation like Avro's spec: http://avro.apache.org/docs/current/spec.html. I mean, Hbase should define for example that an Int32 fixed encoding is X bytes, little endian, and here is how you can read and write to this field. The spec attached at parent issue should be updated once the implementation is final. We should also put that in the book.
- I think for fixed length encodings, we should keep 4 or 8 byte representations. Not sure adding the encoding type as the prefix byte gains us anything.
- For compound keys, it seems that the API provides encodeXXX() and decodeXXX() methods, and byte's are concatenated with ByteBuffers. Will there be any higher level support, or is this enough (just asking to understand).
- On ByteBuffers and ByteRange's, I would say, if possible, we should build the api around raw byte's. We can then wrap these API's with ByteBuffers or ByteRanges.
- I will wait for the new patch for HBASE-8693 to see how the types here (float64) interact with the other types (legacy types in Bytes). The types here are hardcoded here, vs you are proposing a pluggable scheme for types in HBASE-8693.
- I think we are getting rid of H... naming convention. Should we just name HNumeric -> Numeric, etc.