Cullen Jennings
2017-05-13 16:15:01 UTC
We had a good call about URI , URL, and how this all links together but one of the discussion made us realize that for aggregated collections, the current spec is less than ideal and that problem reflected up in multiple ways. So here is the proposal ...
We got back to allowing base attributes to occur in any record and be the base value any record after that up to the point where the base attribute gets set to something else. Take the example of a sensor with IP 2001:db8::2 that is an indoor temperature and humidity sensor that also aggregates in the reading from a similar outdoor device at IP 2001:db8::1. You could represent this wth
[
{"bt":1.320078429e+09,
"n":"2001:db8::2-temperature","u":"Cel","v":25.2},
{"n":"2001:db8::2-humidity","u":"%RH","v":30},
{"n":"2001:db8::1-temperature","u":"Cel","v":12.3},
{"n":"2001:db8::1-humidity","u":"%RH","v":67}
]
Note the IP part of the name is different in the last two records because that is the unique sensor they came from.
But it would be nicer to be able to say
[
{"bn":"2001:db8::2","bt":1.320078429e+09,
"n":"temperature","u":"Cel","v":25.2},
{"n":"humidity","u":"%RH","v":30},
{"bn":"2001:db8::1",
"n":"temperature","u":"Cel","v":12.3},
{"n":"humidity","u":"%RH","v":67}
]
This gives us better compression because we can use a base name for the common IP part of the sensor name.
A very common use case for core is aggregating measurements into one pack so I think this is an important use case. It also resolves the issue we were having with lining up with names and URL which is how we realized we had this issue.
So my proposal is go back to how we used to have it and allow base attributes in Records other than than the first Record. I realize this is flip flopping on a previous decision but I think we forgot about this use case when we went to base values only in the first Record.
Let me know if you see any problems with this.
Thanks,
Cullen
We got back to allowing base attributes to occur in any record and be the base value any record after that up to the point where the base attribute gets set to something else. Take the example of a sensor with IP 2001:db8::2 that is an indoor temperature and humidity sensor that also aggregates in the reading from a similar outdoor device at IP 2001:db8::1. You could represent this wth
[
{"bt":1.320078429e+09,
"n":"2001:db8::2-temperature","u":"Cel","v":25.2},
{"n":"2001:db8::2-humidity","u":"%RH","v":30},
{"n":"2001:db8::1-temperature","u":"Cel","v":12.3},
{"n":"2001:db8::1-humidity","u":"%RH","v":67}
]
Note the IP part of the name is different in the last two records because that is the unique sensor they came from.
But it would be nicer to be able to say
[
{"bn":"2001:db8::2","bt":1.320078429e+09,
"n":"temperature","u":"Cel","v":25.2},
{"n":"humidity","u":"%RH","v":30},
{"bn":"2001:db8::1",
"n":"temperature","u":"Cel","v":12.3},
{"n":"humidity","u":"%RH","v":67}
]
This gives us better compression because we can use a base name for the common IP part of the sensor name.
A very common use case for core is aggregating measurements into one pack so I think this is an important use case. It also resolves the issue we were having with lining up with names and URL which is how we realized we had this issue.
So my proposal is go back to how we used to have it and allow base attributes in Records other than than the first Record. I realize this is flip flopping on a previous decision but I think we forgot about this use case when we went to base values only in the first Record.
Let me know if you see any problems with this.
Thanks,
Cullen