roles CLI standardization

[plebhash]

This Discussion is meant to replace stratum-mining#814

This PR introduced some changes but it wasn't an ideal contribution because it changed too many files. That requires a lot of time before the reviewer understands what is going on.

A more productive form of collaboration could be as Github Discussions.

I will write different posts here in a Request-For-Comment (RFC) style, and we can start discussion threads around each topic.

Hopefully this experiment will prove to be a good communication style for brainstorming and reaching consensus on ideas like:

• coding conventions
• code refactors

[plebhash]

toml dependency replacement

As described in #456, we are pointing to a fork for our toml dependency as a workaround for no_std support.

The toml crate is used to parse the configuration file, but we need some alternative that supports no_std from its upstream source (so it can be fetched directly from crates.io instead of a fork on github.com). So I propose we replace toml with config.

The config crate is the perfect candidate, since it supports TOML as a first-class-citizen and also supports no_std (as I validated on this replit)

[plebhash]

Note: I already have a working implementation of this concept in my fork's standardize-roles-cli branch. That could be used as a living reference to the ideas proposed here. But I'm also happy to adapt those modifications based on how the discussion evolves here.

[plebhash]

clap for managing CLI args

Currently, most of our roles CLI args are parsed directly from std::env::args(). That introduces unnecessary complexity.

clap is a well known crate that provides abstractions for declaration and management of CLI args, so that they can be summarized into a few macros.

This was already introduced by @Fi3 into the implementation of roles/test-utils/mining-device via stratum-mining#819

I propose we standardize this clap-based approach for all roles.

[plebhash]

Note: I already have a working implementation of this concept in my fork's standardize-roles-cli branch. That could be used as a living reference to the ideas proposed here. But I'm also happy to adapt those modifications based on how the discussion evolves here.

[plebhash]

args module split

The way CLI args are declared and parsed is slightly different on each role implementation. There are similar coding patterns, but files are organized under different strategies.

It's not good to have scattered coding patterns across the different roles implementations. If we follow one specific CLI pattern in one role, we should do the same on all roles. This improves readability and maintainability of the codebase.

I propose we standardize roles CLI args as a standalone args module to live on the root level of every role binary crate. This module should have:

• declaration of struct Args with clap macros
• definition of fn process_cli_args(), responsible for returning a *Config object

The args module is already implemented on some roles:

• translator
• jd-client

[plebhash]

Note: I already have a working implementation of this concept in my fork's standardize-roles-cli branch. That could be used as a living reference to the ideas proposed here. But I'm also happy to adapt those modifications based on how the discussion evolves here.

[plebhash]

*Result and *Error structs

Each roles has its own flavor of Result and Error types.

We have a very concise programming pattern around this convention, but unfortunately the variable names are not consistent.

Sometimes they follow a naming-style like RoleResult and RoleError, but sometimes they are simply called Result and Error.

I propose we standardize this so that every role follows the naming-style like RoleResult and RoleError:

• PoolResult + PoolError
• JdsResult + JdsError
• JdcResult + JdcError
• ProxyResult + ProxyError
• TProxyResult + TProxyError

This will avoid name clashes and improve code readability.

[plebhash]

Note: I already have a working implementation of this concept in my fork's standardize-roles-cli branch. That could be used as a living reference to the ideas proposed here. But I'm also happy to adapt those modifications based on how the discussion evolves here.

[plebhash]

*Config structs

The same issue from *Result and *Error also applies to the Config struct. All roles have one, but sometimes they are named under a RoleConfig, or sometimes just Config.

I propose we standardize this so that every role follows the naming-style like RoleConfig:

• PoolConfig
• JdsConfig
• JdcConfig
• ProxyConfig
• TProxyConfig

This will avoid name clashes and improve code readability.

Also, some roles have a standalone module inside lib for the Config declaration (e.g.: roles/translator/src/lib/proxy_config.rs). I propose we also standardize this pattern for all roles, so that each RoleConfig is declared under src/lib/<role>_config.rs:

• jd_server/src/lib/jds_config.rs
• jd_client/src/lib/jdc_config.rs
• mining-proxy/src/lib/proxy_config.rs
• pool/src/lib/pool_config.rs
• translator/src/lib/tproxy_config.rs

Finally, I also propose we standardize that fn get_coinbase_output is always declared inside this module alongside RoleConfig (since it is basically a getter for config.coinbase_outputs). This only applies to pool, JDC and JDS, since proxies do not have coinbase_output on their config files

[plebhash]

Note: I already have a working implementation of this concept in my fork's standardize-roles-cli branch. That could be used as a living reference to the ideas proposed here. But I'm also happy to adapt those modifications based on how the discussion evolves here.