On Fri, Dec 1, 2017 at 4:59 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. >
Consider that any new clients written would have to implement all these encodings. This is going to make writing new clients using the upcoming new protocol laborious. The new protocol does not define object encoding, it strictly defines message encoding. Objects sent over the protocol will have to be serialized in some format, like PDX or data serializer. We could alway develop a better serialization format than what we have now. If we don't develop something new then we have to use the old. Wouldn't it be nice if the new clients didn't have to deal with legacy encodings? If the issue is really the complexity of serialization from the C++ client, > maybe the C++ client could always write UTF-16 strings? > You can't assume that a client in one language will only be serializing strings for it's own consumption. We have many people using strings in PDX to transform between C++, .NET and Java. The risk is high not to remove this debt. If I am developing a new Ruby client I am forced to deal with all 4 of these encodings. Am I really going to want to build a Ruby client for Geode, am I going to get these encodings correct? I can tell you that getting them correct may be a challenge if the current C++ client is any indication, it has a few incorrect assumptions in its encoding of ASCII and modified UTF-8. I am fine with a compromise that deprecates but doesn't remove the old encodings for a few releases. This would give time for users to update. New clients written would not be be able to read this old data but could read and write new data. -Jake
