The current state of single req/res and batch req/res is a bit messy. It probably makes the most sense to treat single req/res as batch req/res as far down in the stack as possible (i.e. close to the raw UDS level). I don't see any reason why servers would want to distinguish between a single request and a batch request with one element.

Option 3 described here

Serde provides a StreamDeserializer struct that should make this fairly trivial at the transport level. The server and client would each pass their UnixStream into a StreamDeserializer (I believe they'd each need to use a SyncIoBridge in between) to create an Iter<serde_json::Value> of incoming requests. The server can simply expose this iterator in its API along with a function where a response can be passed in and sent to the client. However, the client will need to keep track of in-flight requests so it knows where to route responses. This will likely be the most complex part.

According to the JSON-RPC 2.0 spec, notifications are requests that don't contain any id value. Currently we don't even treat a request without an id as valid. We should properly deserialize notifications and treat them as first-class citizens.

• Clients should be able to send notifications to a server and should automatically ignore/reject any notifications received back
• Servers should parse incoming notifications and separate them out before passing them off to their handler