[RFC] Deterministic MN related PRC command naming convention #2385
Description
This issue serves as a place to gather comments and discuss the naming convention for the newly introduced (or soon-to-be introduced) deterministic MN related RPC commands.
Currently, the command names are snake_case, use a protx_ prefix, and are assigned to a new evo category, which introduces a naming convention change to what we use with most of our existing commands.
For reference, our current generally accepted naming convention can be most simply described as follows:
- all lowercase
- no special characters (
-,_,$,#, etc) - use a format of actionsubject (ex: listtransactions, getbalance, fundrawtransaction, setstakesplitthreshold, etc)
This is a table showing the current command names, new proposed names, and any notes:
| Current Name | Proposed Name | Notes |
|---|---|---|
protx_list |
listprotxes |
"protxes" is used as a plural here to denote there can be multiple results |
protx_register |
registerprotx |
Used to send a registration for a pre-existing 10k UTXO residing in this wallet |
protx_register_fund |
fundprotxregistration |
Used to create a new 10k UTXO and send a registration |
protx_register_prepare |
preprareprotxregistration |
Used to create an unsigned registration for a 10k UTXO that resides outside this wallet |
protx_register_submit |
submitprotxregistration |
Used to send a registration after the result from prepareprotxregistration has been signed with the owner address key |
protx_revoke |
revokeprotx |
Revokes the provider's service capability, effectively disabling the DMN |
protx_update_registrar |
updateprotxregistrar |
Used to update operator-specific registration info (operator address, voting address, and payout address). Called by the MN owner |
protx_update_service |
updateprotxservice |
Used to update service-specific registration info (IP address, operator payout address, etc). Called by the MN operator service |
The above are "simple" suggestions, meaning that they use existing verbiage (notably "protx"), which may not be the most ideal in the long term for ease-of-use and understandability, so special consideration should be made in this regard as, while it isn't impossible to change command names after a release, backwards compatibility and deprecation windows add to code clutter.
With regard to the "evo" category, it may make sense to use a unique category name for transitional period of time, just so the new commands are presented in a visually isolated format in help output, however I think we can be a bit more descriptive here as "evo" holds little meaning for PIVX and it's users (it is a acronym reference to the long-awaited DASH Evolution update), and something like "deterministic-mns" might be more appropriate for us.
Finally, and this is a minor issue, but worth mentioning none the less; the filename in the rpc subdirectory that currently holds the code for these new commands is using an outdated naming convention (rpcevo.cpp). Prior to the introduction of the rpc subdirectory, all rpc-related code files were in the base src directory, so it made sense to name them with an rpc prefix. We are long past that now, so there is little sense in continuing that convention.
A transitional file name of simply evo.cpp (or, again, more descriptive for PIVX: dmn.cpp, deterministicmn.cpp, etc) may be more appropriate. In the long run, (ie, after legacy MN code is removed) I would expect the code currently residing in this new file to find it's way into the masternode.cpp and/or budget.cpp files in the same subdirectory.
All of the above should only be acted upon AFTER all the related PRs in this area have been reviewed, tested, approved, and merged into master. The rationale here is that command/file name changing (in both the RPC interface and the testing interface) can be done via a scripted-diff once everything is merged. This not only allows more time for the subject to be discussed, but also makes reviewing such a change rather trivial and straight forward.