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 <[email protected]> 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" <[email protected]> wrote: > > > On Fri, Dec 1, 2017 at 1:48 PM Michael Stolz <[email protected]> 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 > > >
