dear lord, why? this reminds me of the old "xml binary format" joke:
<byte> <bit>0</bit> <bit>0</bit> <bit>1</bit> <bit>0</bit> <bit>0</bit> <bit>1</bit> <bit>0</bit> <bit>0</bit> </byte>
dear lord, why? this reminds me of the old "xml binary format" joke:
<byte> <bit>0</bit> <bit>0</bit> <bit>1</bit> <bit>0</bit> <bit>0</bit> <bit>1</bit> <bit>0</bit> <bit>0</bit> </byte>
Even if they were wedded to JSON for some reason, they could have just used a list of observations, like:
[1458000000,63.422235],
That would have cut their data costs in half.
Or just use one of the many existing formats for transmitting time series data. It's not a new topic. https://github.com/mobileink/data.frame/wiki/What-is-a-Data-...
I'm not saying it's ideal, I just think the snark is unwarranted considering how common it is. I just checked InfluxDB and they follow a similar model (even more verbose). https://docs.influxdata.com/influxdb/v1.2/guides/querying_da...
Checked a few more and I believe they're the same - Microsoft IoT, Predix (GE), etc.
"columns": [
"time",
"value"
],
and then the observations as a list of lists: "values": [
[
"2015-01-29T21:55:43.702900257Z",
2
],
[
"2015-01-29T21:55:43.702900257Z",
0.55
],
exactly as i suggested in the "even if they were wedded to JSON for some reason" section of my original explanation.EDIT: But XML payloads are actually a really useful idea, it's going ASAP to the Trello board. :p
but in all seriousness, why the timestamp at all? your examples are all spaced at 3600ms. asking for it implies certain behavior. can you handle heterogeneous interval data? missing data?