e405786a73
* rpc: add `monero-rpc-types`
* lib.rs: add lints
* add base files, deps
* fix macro generation, doc test
* add `strum`, add `misc` module
* document struct generation macro
* add `GetHeight`
* lib.rs: create re-export macro
* macro changes, add few more types
* docs
* `monero-rpc-types` -> `cuprate-rpc-types`
* fix modules
* specify commit in macro, add () type aliases
* macro docs, fixes
* add `Status::Other(String)`
* add TODO for `strum`
* Update rpc/types/Cargo.toml
Co-authored-by: Boog900 <boog900@tutanota.com>
* add `BinaryString`
* add `ResponseBase`
* add `CORE_RPC_*` constants
* fix status; use `CORE_RPC_*` constants
* cargo.toml: add `epee_encoding`
* rpc: add epee_encoding impl for `Status`
* macro: add epee_encoding for every type
* remove `strum`
* add response bases
* add `CORE_RPC_STATUS_UNKNOWN`
* add response/request bases for epee
* create `base` module
* use different type for macro example
* move base / root types around
* docs, status serde test
* status: use `Status::Unknown` for `epee_default_value`
* json: add missing fields to `GetBlockTemplateRequest`
not sure I missed these
|
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
Monero RPC types.
What
This crate ports the types used in Monero's RPC interface, including:
- JSON types
- Binary (epee) types
- Mixed types
- Other commonly used RPC types
Modules
This crate's types are split in the following manner:
This crate has 4 modules:
- The root module;
cuprate_rpc_types - [
json] module; JSON types from the/json_rpcendpoint - [
bin] module; Binary types from the binary endpoints - [
other] module; Misc JSON types from other endpoints
Miscellaneous types are found in the root module, e.g. [crate::Status].
Each type in {json,bin,other} come in pairs and have identical names, but are suffixed with either Request or Response. e.g. GetBlockCountRequest & GetBlockCountResponse.
Documentation
The documentation for types within {json,bin,other} are omitted, as they can be found in Monero's RPC documentation.
However, each type will document:
- Definition: the exact type definition location in
monerod - Documentation: the Monero RPC documentation link
- Request/response: the other side of this type, either the request or response
Naming
The naming for types within {json,bin,other} follow the following scheme:
- Convert the endpoint or method name into
UpperCamelCase - Remove any suffix extension
For example:
| Endpoint/method | Crate location and name |
|---|---|
get_block_count |
[json::GetBlockCountRequest] & [json::GetBlockCountResponse] |
/get_blocks.bin |
bin::GetBlocksRequest & bin::GetBlocksResponse |
/get_height |
other::GetHeightRequest & other::GetHeightResponse |
TODO: fix doc links when types are ready.
Mixed types
Note that some types within [other] mix JSON & binary together, i.e.,
the message overall is JSON, however some fields contain binary
values inside JSON strings, for example:
{
"string": "",
"float": 30.0,
"integer": 30,
"binary": "<serialized binary>"
}
binary here is (de)serialized as a normal [String]. In order to be clear on which fields contain binary data, the struct fields that have them will use [crate::BinaryString] instead of [String].
TODO: list the specific types.