View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007671 | Taler | exchange | public | 2023-02-10 14:55 | 2024-08-12 09:56 |
| Reporter | sebasjm | Assigned To | |||
| Priority | none | Severity | feature | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | git (master) | ||||
| Target Version | post-2.0 | ||||
| Summary | 0007671: replace positional parameter for named parameters in taler-exchange-offline | ||||
| Description | For example, instead of this taler-exchange-offline -c $CONFIG global-fee 2020 $CURRENCY:0 $CURRENCY:0 $CURRENCY:0 1year 1year 10 upload It should be like this taler-exchange-offline -c $CONFIG global-fee --year 2020 --history-fee $CURRENCY:0 --account-fee $CURRENCY:0 --purse-fee $CURRENCY:0 --purse-timeout 1year --history-expiration 1year --purse-account-limit 10 and maybe, even can be partially filled taler-exchange-offline -c $CONFIG global-fee --year 2020 --history-fee $CURRENCY:0 --account-fee $CURRENCY:0 --purse-fee $CURRENCY:0 taler-exchange-offline -c $CONFIG global-fee --purse-timeout 1year --history-expiration 1year --purse-account-limit 10 taler-exchange-offline upload So it will be harder to break when adding/removing parameters in global-fee and wire-fee | ||||
| Tags | No tags attached. | ||||
|
|
I'm not sure using named parameters is helpful for taler-exchange-offline: there really all parameters are needed, they are not optional. And it is actually good for it to break hard instead of doing something even slightly different from what the user intended. taler-exchange-offline is NOT a tool we'd expect people to ever mess around with without studying the manual closely. And it is better if the scripts break hard, than if they configure something to some 'default' value that is not the right one. |
|
|
Discussed offline: We don't want defaults, the command is supposed to break when a new fee is added. Only experts should use the commands in the first place. But, for usability reasons, we should (IMHO) still eventually do positional arguments, but that's just a syntactic change, which will in turn break existing scripts. So this is lower-priority. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-02-10 14:55 | sebasjm | New Issue | |
| 2023-02-10 14:55 | sebasjm | Status | new => assigned |
| 2023-02-10 14:55 | sebasjm | Assigned To | => Christian Grothoff |
| 2023-02-11 23:04 | Christian Grothoff | Note Added: 0019804 | |
| 2023-02-11 23:04 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2023-02-11 23:04 | Christian Grothoff | Status | assigned => feedback |
| 2023-02-12 17:15 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2023-02-12 17:15 | Florian Dold | Status | feedback => assigned |
| 2023-02-12 17:15 | Florian Dold | Note Added: 0019806 | |
| 2023-02-12 19:03 | Christian Grothoff | Priority | normal => none |
| 2023-02-12 19:03 | Christian Grothoff | Target Version | 0.9.2 => git (master) |
| 2023-02-13 14:17 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2023-02-13 14:17 | Christian Grothoff | Status | assigned => confirmed |
| 2023-04-04 15:54 | Florian Dold | Target Version | git (master) => post-1.0 |
| 2024-01-12 14:05 | Christian Grothoff | Category | exchange API (C) => exchange |
| 2024-08-12 09:56 | Christian Grothoff | Target Version | post-1.0 => post-2.0 |
