Open p4u opened 3 years ago
Do we need to keep some kind of retro-compatibility with old RPC clients?
Also the problem about 64bit integer is not withing JSON itself but in the languages on which are written the RPC clients, Dart and JavaScript are affected but Go/C++ etc. do not, I guess the RPC clients are written in JavaScript, am I wrong? In that case we have to change the representation of all 64bit integers and not just the timestamps in the RPC protocol.
Do we need to keep some kind of retro-compatibility with old RPC clients?
Just saw this @G10h4ck I do not think we need to maintain this retro-compatibility given that the clients we have are updated or in process to be updated to the new specs.
Also the problem about 64bit integer is not withing JSON itself but in the languages on which are written the RPC clients, Dart and JavaScript are affected but Go/C++ etc. do not, I guess the RPC clients are written in JavaScript, am I wrong? In that case we have to change the representation of all 64bit integers and not just the timestamps in the RPC protocol.
Yep you're right, we also have RPC client written in JS, but I do not know if some work around is already implemented, ping @brickpop or @marcvelmer for having better clarity on this. Thank you
Describe the feature Use string timestamps instead of int32
Motivation Support timestamps > year 2038
Proposal Use integers stored in strings - it's just two more characters, and you entirely sidestep the issue of float precision in json :) In Go, they are natively supported like:
Components affected vocdoni-node and dvote-js
Additional information (if required) This change should be perform in paralel for golang and javascript libraries