Add bitreq #1608
No reviewers
Labels
No labels
DB & Storage
Deployment
Error Handling & Logging
Maintenance
Payment Backend
backport
backport v0.13.x
backport v0.14.x
backport v0.15.x
bindings
blocked
bug
cdk-sql
ci
cli
deps
documentation
duplicate
enhancement
good first issue
help wanted
invalid
keep-open
ldk-node-ui
migrations
mint
mutation-testing
needs rebase
needs review
new nut
nut change
question
ready
rust-version
rustfmt
stacked hold
stale
testing
wallet
weekly-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
cashubtc/cdk!1608
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "lescuer97/add_bitreq"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
use bitreq for the non wasm targets and use reqwest for wasm. in the http client crate.
Notes to the reviewers
Suggested CHANGELOG Updates
CHANGED
ADDED
REMOVED
FIXED
Checklist
just final-checkbefore committing@lescuer97 almost there, I think we should remove reqwuest all together and use this bits for wasm, using the native "fetch" function provided by the browser and bitreq for everything else
I don't think we should remove reqwest all together. Can't we make use of a trait and then implement that trait for both bitreq and reqwest, it should only have a couple fns. We can then feature flag these implementations. Many projects already use reqwest so use reqwest within cdk would not be adding any deps and in fact using bitreq would. This would also make it easier for us to switch between the two as bitreq is still new we could encounter issues.
projects already using reqwest is true. I had not think about it
The reqwest feature needs to be added to the cdk and perhaps the mintd crates as well, since the http crate is not injected or cannot be provided externally.
mintd we can just make the choice we don't need to give a feature.
Even if we do not provide the feature externally, I still think it makes sense to do as a trait. Since we know we will have at least 2 impls even if we drop reqwest wasm and native.
okey, just to clear thing up. I will then keep this code but add back the features for
bitreqandreqwest.and reimplement the trait for reqwest.
does this sound correct?
I can help if you want, but I also believe the trait is a good idea and it should live in cdk-common perhaps.
I just remembered we actually have 3 at minimum due to Tor. We already have a trait there maybe we can just move it and consolidate?
github.com/cashubtc/cdk@48e50028af/crates/cdk/src/wallet/mint_connector/transport/tor_transport.rs (L225)@thesimplekid @crodas just to be clear on what to do next. I should keep the trait that already exists in the http package, then use that trait for the tor implementation also. possibly moving that code into the http crate.
plus go back to use features. so users can decide to use either the reqwest or bitreq trait.
We want to move the transport Trait to the http crate. Tor, bitreq and reqwest should all implement this each behind a feature in the http crate. The
MintConnectorshould stay roughly the same in cdk where it takes the Transport trait.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.