rpc: normalize parameter names #20013

pull kallewoof wants to merge 7 commits into bitcoin:master from kallewoof:202009-rpc-normalize changing 6 files +60 −48
  1. kallewoof commented at 8:18 am on September 25, 2020: member

    This PR initiates the transition to using normalized parameter names in objects in RPC commands.

    Because this transition all at once would be huge, the PR also includes a during-transition temporary structure which will make it transparent to the user whether the object has been normalized or not.

    There is also one conversion in here, for the send RPC, to show what conversion would entail.

    This is an alternative to #19957. (A much better alternative, IMO.)

  2. fanquake added the label RPC/REST/ZMQ on Sep 25, 2020
  3. kallewoof force-pushed on Sep 25, 2020
  4. promag commented at 8:36 am on September 25, 2020: member

    Concept ACK

    As an intermediate step I was thinking request.params could have both keys, the original and the normalized (obviously should assert that the normalized key doesn’t conflict with another one). This way it’s not necessary to call NormalizedObject on the RPC methods.

    A next intermediate step would be to remove original keys and only keep the normalized ones, this behavior could be turned on in RPCHelpMan on each RPC method to support small changes.

  5. kallewoof force-pushed on Sep 25, 2020
  6. kallewoof commented at 12:30 pm on September 25, 2020: member

    @promag I tried to work on a solution based on always providing the entire params object recursively normalized, keeping the originals around as well, but it is very easy to mess up. For example if I convert send and leave FundTransaction as it is, the updated send will now put new normalized keys in the options and FundTransaction will fail to find those, even though the initial code had copied everything.

    Since it also adds to named parameters, patches are needed in various places to make it not yell about missing or unknown parameters.

    Still digging, but this seems to increase complexity quite a bit.

  7. DrahtBot commented at 1:04 pm on September 25, 2020: member

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #17211 (Allow fundrawtransaction and walletcreatefundedpsbt to take external inputs by achow101)
    • #16439 (cli/gui: support “@height” in place of blockhash for getblock on client side by ajtowns)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  8. fanquake requested review from Sjors on Sep 29, 2020
  9. fanquake requested review from MarcoFalke on Sep 29, 2020
  10. DrahtBot added the label Needs rebase on Sep 29, 2020
  11. rpc: add RPC parameter normalization functions f61b8ca3b6
  12. rpc: add transition helper for normalized univalues 0f0a6a0d04
  13. rpc: make FundTransaction take a NormalizedUniValue 4ed1c98b8d
  14. rpc: normalize send RPC 560f3b4ae7
  15. kallewoof force-pushed on Sep 29, 2020
  16. fix: inline due to linker issues in next commit 8c3f775c33
  17. rpc: normalize named parameters
    When using -named, this converts all variants of case and underscores into a normalized lower case no underscore parameter name.
    107ab453a2
  18. kallewoof commented at 8:42 am on September 29, 2020: member

    I extended this a slight bit to now also normalize the -named functionality.

    0$ ./bitcoin-cli -regtest -named send out_puts='[{"bcrt1qkfveed8g8vnktsc3490aarzh302l2qc2ymhlge":1}]' conftarget=1 estim_ate_mode=sat/b
    

    In the process, I ran into linker issues with QT build, so I inlined the NormalizeParameterName function. Seems moving it to a shared place between rpc/client and rpc/util, but not clear where.

  19. fix: compile issue 6e6944cf47
  20. DrahtBot removed the label Needs rebase on Sep 29, 2020
  21. kallewoof commented at 7:39 am on September 30, 2020: member
    Expanding on this, I am coming to the conclusion that this is error prone and messy – did you normalize or didn’t you? That would be a continuous problem. @promag’s #20017 seems like a better approach.
  22. kallewoof closed this on Sep 30, 2020

  23. kallewoof deleted the branch on Sep 30, 2020
  24. DrahtBot locked this on Feb 15, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-22 12:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me