idenatoday
commented
4 years ago Thanks for the feedback and future-proof concerns.
We get the versioning concern. Main goal of dnaurl is to rely on a long term open and stable protocol that can safely be used by many providers. Stability - I'd even say conservatism - is then a core concern.
Unlike an API whose calls can change over time and new calls be added, a given dnaurl format is very likely not to change.
dna://sig/ for instance will only ever return a signature if we wanted to return other things, that would be a new dna:// item.
As for raw transactions for instance, data is the core data. So for it to break, would mean the core transaction format changes. Would be a huge change with way more impacts than dnaurls alone.
If this happens, the params count would change - something the lib checks, and would mean every provider would need to update other core components anyway.
At that time, and only if ascendant compatibility is not possible and we want to make sure, we could still add a /v2/ segment - or just call it dna://raw2/...
Most annoying in versioning as part of the default string is that we would add extra data everywhere in every url, just in case someday it could maybe change.
We think our best shot at a common protocol is good, stable specs and good tests on the various implementations so the lib takes care of returning explicit error messages.
Do you see a practical reason why a given dnaurl format would change over time?
EarthlingDavey
Should we consider an ( optional? ) version number for each url type.
It would mean that in the future, any errors occurring from changes/upgrades to the structure can be handled, and in cases of incompatibility, reasons for errors will be obvious.
e.g.
dna://txsig/v1/encoded_sig_buffer/checksum