Current situation
The new feature in 'hdrs' requests allows selecting the data to be provided (with the new 'cabs' and 'crel' parameters). However, it always provides the data in the same order, whatever the order the codes below are actually passed (e.g. 'crel=dfkoOiIC' gives the same result as 'crel=dfkCioIO'). As a consequence, any explorer GUI must reorder the received data in order to have it in the same order as it was requested.
Remark: Block height, timestamp and hash are always provided, as first data.
Solution we propose
1) We propose to have the node explorer provide the data in the same order that was passed in the request (e.g. 'dfkoOiIC' would get the data in an order, while 'dfkCioIO' would get the same data, but in a different order).
2) Also, we propose to then merge 'crel' and 'cabs' as a single parameter so that the sequence of data can mix relative and absolute (cumulative) values, in whatever requested order.
3) Finally, to differentiate relative and absolute values, we propose to use lowercase letters only for the relative values, and their uppercase equivalent for the absolute values. Thus we propose the following adjustment to the codes:
The uppercase equivalents (DFKIOUPQACZS) would then represent the absolute values of the above parameters.
An example of request mixing both relative and absolute values AND defining the order for the data to be provided, could be: 'dDfkioUpqcZS'
4) The default data and order (after block height, timestamp and hash), when no specific request is done, would be "kiopqc" (which represent the most basic information a normal use would need).
dbadol
commented
2 weeks ago
Current situation The new feature in 'hdrs' requests allows selecting the data to be provided (with the new 'cabs' and 'crel' parameters). However, it always provides the data in the same order, whatever the order the codes below are actually passed (e.g. 'crel=dfkoOiIC' gives the same result as 'crel=dfkCioIO'). As a consequence, any explorer GUI must reorder the received data in order to have it in the same order as it was requested.
Remark: Block height, timestamp and hash are always provided, as first data.
Solution we propose 1) We propose to have the node explorer provide the data in the same order that was passed in the request (e.g. 'dfkoOiIC' would get the data in an order, while 'dfkCioIO' would get the same data, but in a different order).
2) Also, we propose to then merge 'crel' and 'cabs' as a single parameter so that the sequence of data can mix relative and absolute (cumulative) values, in whatever requested order.
3) Finally, to differentiate relative and absolute values, we propose to use lowercase letters only for the relative values, and their uppercase equivalent for the absolute values. Thus we propose the following adjustment to the codes:
The uppercase equivalents (DFKIOUPQACZS) would then represent the absolute values of the above parameters.
An example of request mixing both relative and absolute values AND defining the order for the data to be provided, could be: 'dDfkioUpqcZS'
4) The default data and order (after block height, timestamp and hash), when no specific request is done, would be "kiopqc" (which represent the most basic information a normal use would need).