jsonrpc comments are slightly incorrect

[mpcm]

There are a couple references to the jsonrpc implementation in xi not being fully 2.0 compliant because of the peer-to-peer async nature, in the comments/readme. This is not quite right, as the 2.0 specifically considered this type of use case, by avoiding transport specifics (including direction). Granted, it isn't often used this way in the wider web... but it was definitely considered at the time.

The wording might be the sticking point, but "The Client is defined as the origin of Request objects and the handler of Response objects." phrasing tries to make this clear. Peers communicating using jsonrpc objects are just filling those roles with each other, or one role at a time in a specific context, depending on how it is coded/considered.

Fair enough on calling out not supporting batch and dropping the jsonrpc member though, chrome and others do the same, it is always tempting to do to drop the payload size/noise, especially on internal component communications. But always easy enough to add that member back in, should anything decide to push the objects out to another spec compliant jsonrpc server over the wire or into another non-internal context/language.

Interesting project, just wanted to chime in to clarify...

[jansol]

@mpcm tbh I'm not familiar at all with jsonrpc, would you mind opening a PR with your suggested wordings? (Sorry to have let this go unnoticed for so long)

[mpcm]

No worries, I think I only ended up here because someone pointed it out somewhere else in another context. I'll open a PR once I can update the text...