From 96997d28614afa5f8eba5fe152173e9d8c412853 Mon Sep 17 00:00:00 2001 From: valued mammal Date: Thu, 5 Sep 2024 18:34:13 -0400 Subject: [PATCH] wip: add persisted ADR --- docs/adr/0002_persisted.md | 69 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 docs/adr/0002_persisted.md diff --git a/docs/adr/0002_persisted.md b/docs/adr/0002_persisted.md new file mode 100644 index 000000000..27589a644 --- /dev/null +++ b/docs/adr/0002_persisted.md @@ -0,0 +1,69 @@ +# Introduce `PersistedWallet` + +* Status: accepted +* Deciders: [list everyone involved in the decision] +* Date: 2024-08-19 + +Technical Story: PR [#1547](https://github.com/bitcoindevkit/bdk/pull/1547), [ADR-0001](./0001_persist.md) + +## Context and Problem + +We would like persistence operations to be both safe and ergonomic. It would cumbersome and error prone if users were expected to ask the wallet for a changeset at the correct time and persist it on their own. Considering that the wallet no longer drives its own database, an ideal interface is to have a method on `Wallet` such as `persist` that the user will call and everything will "just work." + +## Decision Drivers + +* [driver 1, e.g., a force, facing concern, …] +* [driver 2, e.g., a force, facing concern, …] +* … + +## Considered Options + +* [option 1] +* [option 2] +* [option 3] +* … + +## Decision Outcome + +Chosen option: Introduce a new type `PersistedWallet` that wraps a BDK `Wallet` and provides a convenient interface for executing persistence operations aided by a `WalletPersister`. + +### Positive Consequences + +* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] +* … + +### Negative Consequences + +* [e.g., compromising quality attribute, follow-up decisions required, …] +* … + +## Pros and Cons of the Options + +### [option 1] + +Open questions + +* How does a user know when and how often to call `persist`? (Short answer: whenever we mutate the wallet) + +### [option 2] + +[example | description | pointer to more information | …] + +* Good, because [argument a] +* Good, because [argument b] +* Bad, because [argument c] +* … + +### [option 3] + +[example | description | pointer to more information | …] + +* Good, because [argument a] +* Good, because [argument b] +* Bad, because [argument c] +* … + +## Links + +* [Link type] [Link to ADR] +* …