This allows it to talk to things like bitcoind. It still wants a tcp
socket as its transport -- but it can at least now be wrapped in HTTP
for bitcoin as well as re-use of the same code for ElectronX style
linefeed based JSON.
Our RPC lib is nowhere near 100% generic and re-usable but it's a good
first step here with this refactor job.
This should hopefully fully complete our implementation to support
JSON-RPC 2.0 without batching. We still are missing batching but at
least now we implement the non-batching portion of the spec more
completely.
It turns out server should always ignore notifications it wasn't
expecting and never respond to them.
What I was doing by returning errors was incorrect.
Instead we add to the error tally for unknown notifications and
eventually disconnect the client.
Also added preliminary support for param maps . . .
I restricted the possible underlying types it can contain down to
qint64, QString, and nullptr_t. This should make it more type safe since
we don't want it to inadvertently end up holding lists or maps
(previously it was a straight up QVariant).
It has a conversion to QVariant so it should work nicely.
- It made the code potentially slower
- Made modifying/adding methods too complex
- Wasn't very beneficial.
- Instead, we just verify JSON-RPC 2.0 spec in the core Connection
class, then we pass on the method call to the subclass if it's found in
the methodlist, etc.
- It's still a little more restrictive than the spec allows -- doesn't
like non-positive-int 'id'
- We not made the shuffle.spec status report back 'notifications' to the
client rather than repeated 'result' messages (as those would be out of
spec). The first response to a 'shuffle.spec' request is either
result="pending", result="accepted", or an error response
- Subsequent shuffle.spec status changes come as a method notification
for "shuffle.spec" with params=["accepted"] or params=["some error
message"]
Overall I think our bare bones JSON-RPC will at least not break now as
interop with other impls.
Now we can re-use the RPC method<->result code in the TcpServer side
which will face wallets. Phew! Took me long enough!
It's a minimal JSON-RPC protocol impl.. but it'll do.
The 1 nice bit is the Schema spec I came up with which more-or-less
works well enough as a first-pass validatior.
Further passes are needed in interested client code, but the initial
pass validation can be done in a thread so as to not waste the main
thread's time validating json or dict key presence/absense. Yay.
