Refact rpc client to use jsonrpcs Client directly, server support for named and null parameters.#787
Draft
jaoleal wants to merge 3 commits intogetfloresta:masterfrom
Draft
Refact rpc client to use jsonrpcs Client directly, server support for named and null parameters.#787jaoleal wants to merge 3 commits intogetfloresta:masterfrom
jaoleal wants to merge 3 commits intogetfloresta:masterfrom
Conversation
Collaborator
Author
Collaborator
|
Concept ACK The idea of using the RPC client directly is interesting. It appears to be easier to understand and reduces our code maintenance burden. |
Collaborator
Author
|
Actually, instead of using rust-bitcoins rpc ive been seeing this other crate which appears to be even more extensive about jsonrpc and rpc in general... Being production ready, used by many people and should be better in order to have a robust clien-server |
807ec46 to
b4b3172
Compare
Collaborator
Author
|
Im reconsidering this, im thinking to actually copy paste jsonrpc inside floresta-rpc. Why?
|
The previous commit introduced the changes where we delegate the request building to jsonrpc which was building some request with null params, breaking our current code that was expecting an array. Since now the server type holds a Option<Value> I separated methods that required params and those who didnt, and added support to getting value from objects by strings, supporting named parameters. I also added a simple test to be sure that named parameters are supported.
b4b3172 to
8b52dd8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description and Notes
floresta-clicore-compatible for us to better test our schema compatibility and achieve what i mentioned heref6a3311: With this proposal in mind I moved our floresta-specific RPC code to a proper module expecting it to receive more RPC handling over types. "floresta-rpc should hold only client implementation", well if we really need to stick with that and consequently still have problems with type re-implementation and drifting maybe we should consider nuking it totally and moving these to floresta common since we would need only some work-arounds to corepc-client to satisfy the support for floresta, which is not an horrible idea IMHO... But is MUCH more conformable to not to.Dropped the related commit, Im thinking that may be better to use another lib to handle server and client for us...
How to verify the changes you have done?
cargo build cargo test -p floresta-rpcThe tests are all returning 422 Http error Lol, Ill debug that because we may be doing something wrong Client or Server side... because of that, draft for now.Found the bug and it was indeed our side... Ill add the third commit fixing the bug since it introduces a lot of changes server side.
Contributor Checklist
just pcc(recommended but slower)just lint-features '-- -D warnings' && cargo test --releaseFinally, you are encouraged to sign all your commits (it proves authorship and guards against tampering—see How (and why) to sign Git commits and GitHub's guide to signing commits).