I think I'm kinda with Mike on this one. The existing string format does seem pretty gnarly. But the complexity of implementing and testing all of the backwards compatibility transcoding that would be required in order to move to the new proposed format seems to be way more work with much more possibility for errors. Do we really expect people to be writing new clients that use DataSerializable? It hasn't happened yet, and we're working on a new protocol that uses protobuf right now.
If the issue is really the complexity of serialization from the C++ client, maybe the C++ client could always write UTF-16 strings? -Dan On Fri, Dec 1, 2017 at 4:17 PM, Michael Stolz <mst...@pivotal.io> wrote: > My opinion is that risk/reward on this on is not worth it > > -- > Mike Stolz > Principal Engineer - Gemfire Product Manager > Mobile: 631-835-4771 > > On Dec 1, 2017 5:19 PM, "Jacob Barrett" <jbarr...@pivotal.io> wrote: > > > On Fri, Dec 1, 2017 at 1:48 PM Michael Stolz <mst...@pivotal.io> wrote: > > > > > There also would likely be Disk Stores that would need to be converted. > > > That would be real ugly too. > > > > > > Disk store could transcode each entry on demand or all at once on first > > load. Not saying it will be easy but progress rarely is. > > > > -Jake > > >
