On 2020/07/23 03:23:58, Chia-Ping Tsai <chia7...@apache.org> wrote: > Thanks for quick feedback! Ismael > > > Are there options with lower impact that still help us achieve the goal for > > those who need it? > > For example, it could be an opt-in thing instead of forcing the world to > > change. > > It seems to me there are two alternatives. > > 1. Introduce an new extended serializer (there is an existent but deprecated > one). if the serializer is extended type, we call new method to get > ByteBuffer. Users who have no interest of ByteBuffer keep using standard > Serializer interface. > 2. Don’t deprecate the existent serialize methods. users are not under the > pressure of API migration I guess the Deserializer could have both `byte[]` and `ByteBuffer` deserialization method. The code would call the `ByteBuffer` one, its default implementation would be to convert to `byte[]` and call the `byte[]` one with Utils.toArray, as is done in the Fetcher today. This should stay compatible with existing deserializer while making it possible to deal with ByteBuffer or `byte[]`.
