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 -- Chia-Ping On 2020/07/22 17:16:37, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Chia-Ping, > > Thanks for the KIP. It seems like the path chosen here would cause a > massive impact to user code. 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. > > Ismael > > On Wed, Jul 22, 2020 at 9:43 AM Chia-Ping Tsai <chia7...@apache.org> wrote: > > > hi folks, > > > > I would like to discuss KIP-646. The KIP plans to use ByteBuffer to be the > > return type of Serializer#serialize. It opens the door to manage the memory > > more effectively and flexible. > > > > https://cwiki.apache.org/confluence/x/RiR4CQ > > > > The change involved by this KIP is huge so it would be better to get > > enough feedback before starting to work :) > > > > Cheers, > > Chia-Ping > > >
