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.)
fanquake added the label
RPC/REST/ZMQ
on Sep 25, 2020
kallewoof force-pushed
on Sep 25, 2020
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.
kallewoof force-pushed
on Sep 25, 2020
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.
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.
fanquake requested review from Sjors
on Sep 29, 2020
fanquake requested review from MarcoFalke
on Sep 29, 2020
DrahtBot added the label
Needs rebase
on Sep 29, 2020
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.
fix: compile issue6e6944cf47
DrahtBot removed the label
Needs rebase
on Sep 29, 2020
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.
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-11-21 21:12 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me