john malkovich wrote:
so the question is: - both "clientHash" and "serverHash" should be replaced with the actual hash of the protocol json definitions?
Yes. Note that the hashing is always done by the owner of the protocol definition, to make it immune from whitespace differences, etc. So the client and server each compute the hash of their own protocol and use the hash of the other's as an opaque cache key.
- what is the "server protocol"? if client and server are compatible dont they both use the same protocol definition?
They might have different versions of a protocol. Messages may have been added or removed. In general, the only compatibility that's needed is that: 1. the server's schema has messages whose names match those of the client's actual requests; 2. the server's schema has default values for request parameters that the client does not provide; and 3. the client's schema has default values for fields of responses that the server does not provide.
Only (1) is presently a hard requirement. For (2) and (3) implementations may fail if they treat missing fields without default values as required, or might be able to proceed if they can handle these as unset. There's been some discussion about mandating that such values are required. But even if that were done then I'm not sure we'd check it at the time of the handshake, since the client may never send the offending messages.
- the "type": ["null", "string"] syntax means that "type" key has either "null" or "string" value?
Yes. JSON arrays are used to signify union types. Doug
