* remove redundant gcsafe/raises
* rework async raises to chronos 4.0 where this was not yet done
* streamline logging between http/socket/ws
* don't log error when raising exceptions (whoever handles should log)
* debug-log requests in all variants of server and client
* unify ipv4/ipv6 address resolution, with preference for ipv6
* fix server start so that it consistently raises only when no addresses
could be bound
* adds processClientHook
This is useful to shape the request and response to defined protocols (i.e. lsp)
* overloads tryRoute
* apply suggestions
* update test
This addresses two items:
- Use ApplicationError instead of InvalidRequest for custom
application errors. Avoiding confusing regarding the usage of
InvalidRequest (although the actual error code used could/would
be different).
- Allow for defining an optional data object that gets returned
in the error response, as per json-rpc specification.
* Add framework to support more optional types
This PR add a framework to rpc server by using more templates than macros to handle optional types.
Now rpc server recognize both `std/options` and `results.Opt` as optional type for the parameters.
If needed user can add more optional types by overloading `rpc_isOptional` template.
Now aliases to optional types also works.
* Don't expose types used internally by the wrapper
* Upgrade rpc router internals
* use new chronos asyncraises
* Fix style mismatch
* Fix nim v2 compilation error
* Addresing review
* Remove unnecessary custom serializer and let the library do the work
* fix error message
* Update readme.md
* fix enum parsing, work around potential `nil` dereference
When the bizarre error handling in the http client fails, it may happen
that a nil is returned (maybe due to Nim bugs) - do it manually for now
when an rpc method in server throw `InvalidRequest` using custom error code,
the router need to mention the request id too.
otherwise the client will throw error with confusing message.
The users will be now able to write RPC handlers returning the
distinct type `StringOfJson`. This will bypass any use of the
standard library's JsonNode type and its serialization routines.
The change was motivated by the integration of JSON-RPC in
status-im/nim-beacon-chain where most of the data types cannot
be handled by Nim's std lib or json-rpc's jsonmarshal module.
Be careful when creating templates. If the input parameters are
referenced within the body multiple times, this may lead to multiple
evaluations of functions with side-effects.
