2019-01-24 12:21 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005506Talerexchange API (HTTP specification)public2019-01-08 19:00
ReporterMarcello Stanisci 
Assigned ToChristian Grothoff 
PrioritylowSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionwon't fix 
Product VersionSVN HEAD 
Target Version0.6Fixed in Version0.6 
Summary0005506: Should "last_issue_date" screen signkeys as well?
DescriptionThe current API lets "/keys?last_issue_date=XXX" screen *only* denomination keys per their timestamp. Shall this timestamp-based screening happen for signkeys as well?

Although this suggested change doesn't improve significantly performance - signkeys are just "little" - it might save the user from getting confused by seeing only one type of key being screened, and not all of them.
TagsNo tags attached.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]



Christian Grothoff (manager)

I've checked, and this is actually not easily (or sanely) doable. for signing keys, we return the current one and those "a bit into the future", but the "bit into the future" can change depending on the exchange configuration. Also, in any case, this should only ever return a handful of keys. So doing this *brittle* optimization to possibly save a few bytes of bandwidth makes no sense.

-Issue History
Date Modified Username Field Change
2019-01-08 18:33 Marcello Stanisci New Issue
2019-01-08 18:33 Marcello Stanisci Status new => assigned
2019-01-08 18:33 Marcello Stanisci Assigned To => Christian Grothoff
2019-01-08 18:33 Marcello Stanisci Priority normal => low
2019-01-08 19:00 Christian Grothoff Note Added: 0013448
2019-01-08 19:00 Christian Grothoff Status assigned => resolved
2019-01-08 19:00 Christian Grothoff Resolution open => won't fix
2019-01-08 19:00 Christian Grothoff Fixed in Version => 0.6
2019-01-08 19:00 Christian Grothoff Severity minor => feature
2019-01-08 19:00 Christian Grothoff Product Version => SVN HEAD
2019-01-08 19:00 Christian Grothoff Target Version => 0.6
+Issue History