...

• An alternative approach is to include this information into the handshake, which eliminates an extra request. However, a single partition-aware client performs a handshake with multiple server nodes. Binary configuration is guaranteed to be the same on all nodes in the cluster, so the client only needs to request it once. As a result, it is more efficient to perform one extra request than extending the handshake message.
• When "custom" mapper type is returned by the server, client is supposed to check that local BinaryConfiguration has a custom name mapper defined, and log/throw and error otherwise. We could return the type name of the custom mapper from the server, but it is of little use - we can't validate the client-side type name in non-Java clients, and even with Java client the class name can be different.

Compatibility Risks

• Java thin client has compactFooter=false by default, even though it is true by default on the server.
• Python, PHP, Node.js, C++ thin clients do not support compactFooter at all.

Therefore, we must ensure that the behavior never changes from false to true on existing clusters, because some thin clients won't be able to read the data with compact footers.

Discussion Links

Dev List: IEP-66: Thin Client Automatic Binary Configuration

...