View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004521 | Taler | other | public | 2016-05-23 13:53 | 2016-11-20 03:26 |
| Reporter | Florian Dold | Assigned To | Marcello Stanisci | ||
| Priority | normal | Severity | text | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.0 | ||||
| Target Version | 0.2 | Fixed in Version | 0.2 | ||
| Summary | 0004521: inconsistent terminology: edate vs expiration date vs refund deadline | ||||
| Description | edate seems to stand for "expiration date", but in the code/config we use it for the wire_deadline. This is confusing, we should agree on a consistent terminology. | ||||
| Tags | No tags attached. | ||||
| related to | 0004645 | closed | Christian Grothoff | Refactor of Taler API's documentation |
|
|
To make things worse, the contract also has an "expiry" field, which is the expiry date of the contract. |
|
|
I'd suggest the 'exp_' (or 'expiration_') prefix for those fields which indicate an expiration, and 'date_' for those who indicates a precise point in the time when something should happen; so the naming becomes: - exp_contract (in place of "expiry") - exp_refund (in place of "refund_deadline") - date_wire (in place of "edate"/"wire_deadline") |
|
|
I don't see how this makes sense. Except for EDATE in the configuration (which is a relative time), these are all deadlines (absolute time). By the way, looking at the source code, edate stands for execution data and not expiration date. We should just find a better name for "edate" in the config, and have a less ambiguous name for the "expiration" field of the contract. |
|
|
I'm generally for spelling things out long, rather than having obscure and possibly misunderstood short names. |
|
|
"edate" becomes absolute when it is a field in the deposit permission [1]. For consistency/readability, we should use the same name for config values that are (or originate) a JSON field. Alternatively, if some relative time in configuration originates a JSON field x, that value may be called x_delta. In practice, the config value 'date_wire_delta' originates 'date_wire' in the deposit permission's JSON. Anyway, the meaning of 'expiration_x = y' is "do x *not later than* y" and for 'date_x = y' is "do x *at time* y"; regardless of the fact that their value originated from an absolute or relative time. [1] http://api.taler.net/api-exchange.html#post--deposit |
|
|
expiration (in contract) should become pay_deadline (last chance to pay, offer ends). edate should become wire_transfer_deadline for absolute, and wire_transfer_delay for configuration (relative). |
|
|
edate change done (in exchange, merchant, api and deployment). |
|
|
I cannot really find 'expiration' in the merchant's source code, which is odd. Maybe we currently do not check it? (but should...?). Changing 'expiration' to 'pay_deadline' right now seems to be simply a very small change in the API. Marcello, could you please do this (and add a check for expired contracts on /pay in the backend?) |
|
|
fixed in merchant 2854239 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-05-23 13:53 | Florian Dold | New Issue | |
| 2016-05-23 13:55 | Florian Dold | Note Added: 0010706 | |
| 2016-05-23 20:34 | Marcello Stanisci | Note Added: 0010712 | |
| 2016-05-23 20:36 | Marcello Stanisci | Note Edited: 0010712 | |
| 2016-05-23 20:41 | Florian Dold | Note Added: 0010713 | |
| 2016-05-23 23:23 | Christian Grothoff | Note Added: 0010715 | |
| 2016-05-23 23:23 | Christian Grothoff | Severity | minor => text |
| 2016-05-23 23:23 | Christian Grothoff | Status | new => acknowledged |
| 2016-05-23 23:23 | Christian Grothoff | Product Version | => 0.0 |
| 2016-05-23 23:23 | Christian Grothoff | Target Version | => 0.1 |
| 2016-05-23 23:31 | Marcello Stanisci | Note Added: 0010716 | |
| 2016-05-24 00:57 | Marcello Stanisci | Note Edited: 0010716 | |
| 2016-05-24 20:52 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2016-05-24 20:52 | Christian Grothoff | Status | acknowledged => assigned |
| 2016-05-26 14:51 | Christian Grothoff | Note Added: 0010766 | |
| 2016-05-26 15:25 | Christian Grothoff | Note Added: 0010767 | |
| 2016-05-26 15:50 | Christian Grothoff | Note Added: 0010769 | |
| 2016-05-26 15:50 | Christian Grothoff | Assigned To | Christian Grothoff => Marcello Stanisci |
| 2016-09-07 16:58 | Marcello Stanisci | Relationship added | related to 0004645 |
| 2016-09-27 22:29 | Christian Grothoff | Target Version | 0.1 => 0.2 |
| 2016-10-20 14:27 | Marcello Stanisci | Note Added: 0011362 | |
| 2016-10-20 14:27 | Marcello Stanisci | Status | assigned => resolved |
| 2016-10-20 14:27 | Marcello Stanisci | Resolution | open => fixed |
| 2016-11-15 16:03 | Christian Grothoff | Fixed in Version | => 0.2 |
| 2016-11-20 03:26 | Christian Grothoff | Status | resolved => closed |
