View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007452 | Taler | wallet-core | public | 2022-11-14 02:58 | 2023-09-23 16:02 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Product Version | git (master) | ||||
| Target Version | post-1.0 | ||||
| Summary | 0007452: extend GetExchangeTos wallet operation to be reuse for backup or auditor | ||||
| Description | Wallet will be accepting ToS from other service, it will be useful to reuse the same logic. Currently I need something similar for backup providers. | ||||
| Tags | No tags attached. | ||||
|
|
I actually do not think that these operations are sufficiently similar enough to abstract them out. The exchange ToS is human-readable text with an Etag, while the sync ToS is structured JSON without any versioning. |
|
|
What is the difference between the ToS that backup service provider and auditor uses? Can we make a standard way of creating, serving, querying and displaying ToS for every service so we no need to build particular solutions for every service? I think that the exchange implementation is good enough to be replicated, and we can reuse the same logic in the wallet (and ui) |
|
|
The main problem here is that the ToS of different services (exchange vs. auditor vs. sync) do not share a lot of structure: * auditor: do we even have ToS here yet? * exchange: multi-language, multi-format human-readable document, ETag for version tracking (also, we might want to stop storing the ToS document, and only store which ETag was accepted by the user, as there's not a real need to review the exchange ToS while offline) * sync: JSON format to explain fees of the service, unversioned In general it's not a good idea to create an abstraction over things that are too different. |
|
|
I'm confused by Florian's comment: the ToS of the different services use *exactly* the same code server-side, and should follow the same structure. Sure, the auditor doesn't yet have a ToS, but that's likely a matter of time. exchange, sync, merchant & anastasis, all use the same logic with ETag and support returning in format requested by the client. They are also all versioned, so the same abstraction makes sense client-side. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-11-14 02:58 | sebasjm | New Issue | |
| 2022-11-14 02:58 | sebasjm | Status | new => assigned |
| 2022-11-14 02:58 | sebasjm | Assigned To | => Florian Dold |
| 2023-01-10 18:37 | Christian Grothoff | Target Version | 0.9.1 => 0.9.2 |
| 2023-01-13 17:04 | Christian Grothoff | Severity | minor => feature |
| 2023-01-13 17:04 | Christian Grothoff | Target Version | 0.9.2 => 0.9.3 |
| 2023-03-28 20:28 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-03-28 20:28 | Florian Dold | Status | assigned => feedback |
| 2023-03-28 20:28 | Florian Dold | Note Added: 0019986 | |
| 2023-03-28 20:29 | Florian Dold | Target Version | 0.9.3 => 0.9.4 |
| 2023-04-01 16:53 | sebasjm | Note Added: 0020001 | |
| 2023-04-01 16:53 | sebasjm | Assigned To | sebasjm => Florian Dold |
| 2023-04-03 19:19 | Florian Dold | Note Added: 0020004 | |
| 2023-04-03 19:19 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-04-09 21:46 | Christian Grothoff | Note Added: 0020042 | |
| 2023-04-10 14:52 | sebasjm | Status | feedback => assigned |
| 2023-04-13 20:36 | Florian Dold | Category | wallet (TS core) => wallet-core |
| 2023-09-23 16:02 | Christian Grothoff | Target Version | 0.9.4 => post-1.0 |
