cln-rpc: Oxidizing c-lightning #5010
Conversation
cdecker
force-pushed
the
cln-rpc
branch
3 times, most recently
from
4c972f6
to
c939b18
Compare
|
Ok, this should be ready to start reviewing, the discussion started with @elsirion is definitely one point I'd like to dig in. The |
|
Thanks for the review @vincenzopalazzo. I chose |
cdecker
force-pushed
the
cln-rpc
branch
3 times, most recently
from
7e45678
to
37fd5c7
Compare
|
Following the discussion with @elsirion I went and simplified the I don't think we need to differentiate off-chain and on-chain amounts for now, but they'd be easy to introduce later on. The range-diff can be found here: https://bot.bitcoinstats.com/ElementsProject/lightning/pull/5010/range_diff/7e456784ed2fac1871340e60e211f331b461eae6..37fd5c7b9a11fc6e5f0758520ee8feed34b3d8b4 |
There was a problem hiding this comment.
ACK 4c12c50
Maybe add the Changelog-Add: .... can be a good information to have inside the changelog?
We build an in-memory model of what the API should look like, which will later be used to generate a variety of bindings. In this PR we will use the model to build structs corresponding to the requests and responses for the various methods. The JSON-RPC schemas serve as ground-truth, however they are missing a bit of context: methods, and the request-response matching (as well as a higher level grouping we'll call a Service). I'm tempted to create a new document that describes this behavior and we could even generate the rather repetitive JSON schemas from that document. Furthermore it'd allow us to add some required metadata such as grpc field numbering once we generate those bindings. Changelog-Added: JSON-RPC: A new `msggen` library allows easy generation of language bindings for the JSON-RPC from the JSON schemas
We're generating these structs so we can parse them directly into native objects.
These are required so we can generate the requests, not just the responses. We'll add more as we test compatibility with our generation code.
We detect whether we have the rust tooling available (mainly `cargo`) and enable or disable the rust libraries, plugins and examples when it is enabled. Since the rest of the Makefiles assumes that executables have an associated header and C source file, we also needed to add a target that we can add non-C binaries to.
Changelog-Added: cln-rpc: A new Rust library called `cln-rpc` can be used to interact with the JSON-RPC
No point in retesting yet again, just test what wasn't tested elsewhere.
|
Re-applying Rusty's ACK after fixing the redundant check in ACK f48f898 |
cln-rpcis the first step towards adding rust as a language to c-lightning. It consists of the following steps:msggento generate a variety of messages from the JSON-RPC schemas, and maybe soon from the wire CSV files.RUST=1(whethercargois in the path or not)msggenis currently based off of the JSON-RPC schemas, but the schemas are lacking some of the higher level concepts such as methods (binding request and response together) or services (binding multiple methods into a grouping). We could eventually create a new root document and make the JSON-RPC schemas derived from that. This would have the advantage of reducing the very verbose JSON-schemas, and being a superset of the information we need for various formats (grpc field identities for example which must not change despite schema evolutions). However I decided against bikeshedding that format for now, and will revisit it in the future.We are still missing quite a few request schemas, which is why not all methods are mapped at the moment. It's gruntwork that I'll add in a separate PR.