john malkovich wrote:
so how is the schema compatibility handled now in Java? Im assuming that Java is the most compliant implementation. Otherwise you would have to count on runtime exceptions to pick up incompatibilities, which is what I think I saw in python implementation (I could be wrong). what am I missing?
Currently we do not check such compatibility at handshake-time, but rather only at runtime. This permits, e.g., a client's protocol to contain a message that the server does not implement. So long as the client does not in fact send that message all's well.
We could perhaps tighten things so that, requiring that the message names in a client's protocol are a strict subset of those on the server. But I fear this would make protocol evolution more difficult in some cases. We expect a protocol to evolve primarily by adding new messages (or adding parameters to existing messages). If an old client is talking to a new server, then the subset rule would work fine. But if a new client is talking to an old server it would not. In many cases this is perhaps appropriate. However a client might be able to detect that it is talking to an old server (via, e.g., the absence of a new field in a prior response, or even a getVersion() message) and only to send old messages to old servers. We don't want to prohibit such things.
The goal is not to automatically solve all protocol evolution problems, but rather to provide a means where varying versions can continue to interact with predictable outcomes, a platform that permits building systems that evolve. My belief is that before someone can be confident that a new service works with old clients and that a new client works with old services, they need to run exhaustive tests between these. Attempting to determine this statically will limit functionality without providing real confidence.
Does this seem reasonable? Or do others feel that more static checking at handshake time would be beneficial?
Doug
