Consider a leaner protocol (backwards compatible)

[setreadygo]

Love what you guys are doing, I was going to implementing my own json 2.0 RPC in exactly the same way until I found your project. I have some ideas for improvement with the spec. The official spec is quite old now (2013), so I propose an unofficial 3.0 that is backwards compatible with 2.0:

1. Version string needs to be only acquired once on initialization. A metadata request is sent when the client connects and the server reports back. If no request is made the server defaults to 2.0. If the server sends an error message back then the client defaults back to 2.0. Now we can do whatever we want without worrying about protocol incompatibility. In javascript it would look like this

socket.once('data', handleMetadata).on('data', handleData)
socket.write(JSON.stringify({ jsonrpc: "2.0", method: "@__version", params: "3.0", id: "" })

2. Keys can be shortened: { m: "...", k: "...", p: { ... } }
3. One struct used for both requests and responses { m: 0, k: "...", p: "error msg" }
4. Key order enforced for quicker encoding/decoding, no whitespace (excluding the param field) should also be enforced for decoding. Only the params field needs to be encoding/decoded which fixes Request<T> and Response<T> for faster serialization #212. The params payload is always last.
5. pubsub required for 3.0 compliance. As of right now you guys are implementing pubsub, but I can't find anything that supports it because it's not in the 2.0 spec. I've resorted to making my own javascript implementation

Other ideas:

• Compression support, not worth it in my opinion because you can just compress the params field when you need to for large data in specific functions. The way it would work is the client and server communicate which compressors they support and agree on something and use that.
• Different serialization formats. Also not really worth it because json tends to be the quickest, but you could do the same as above and have the two discuss which codecs they support and which the client prefers like msgpack or whatever.
• Drop the json spec for the header and use it only for the payload. Use something like semicolon delimited fields like methodname;key;{....}
• Go even further and use json values with positional arguments. methodname;key;arg1;arg2;

Anyways, this stuff is all rather minor but I wanted to throw the idea out there. It may be easier to have an inefficient 2.0 protocol and create a tighter 3.0 spec that makes it easy to implement in rust than it would be to try to wrestle with rust to make an optimized 2.0 implementation.