It could always WRITE UTF-16 strings, but it will still need to be able to read the others.
-- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 On Fri, Dec 1, 2017 at 7:58 PM, Dan Smith <dsm...@pivotal.io> wrote: > 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 > > > > > >
