We read and write the json 'resource' subtree within the JSON item on this page.
The web addressable data on this page is easily readable with an external link. json
Sensor feed from jd.local screen json. Raw format at present. Soon to be converted to wiki friendly format.
Data is from the 'a' series of sensors also reported by the legacy SensorServer software. site
See Data in Context where pages pool data to be assembled into one large graph database.
We allow regular mechanical updates without relying on the journal to keep this history. The plugin makes some effort to report change but this sidestepping of the journal breaks our notion of forking from history. github
# Markup
I've looked into implementing the jq json manipulation package as a dsl for formatting posted resources. I find it too powerful to be a convenient markup. It feels more like programming than I would like.
Here I will test some markup ideas that should make it easy to post and easy to markup with an eye toward sources we support or are likely to eventually support.
KEEP 100 — save the last 100 posts. This would be interpreted server side. But how does this interact with editing? Merge? Reset to empty on save?
TIMESERIES Key — source a kept value as a measurement over time. This could estimate epoch for each sample knowing interval or by finding a date or time field. Search json breadth first until Key is found.
What about units and conversion noise?
What about aggregation, percentile, missing data?
# Security
We have not yet chosen a mechanism for creation and distribution of access tokens. We have one for now which demonstrates our intention but offers no security.
We should consider who can grant access by minting tokens. Choices include the logged-in site owner, the logged-in server administrator, or the operator with ssh access to the installation.
Consider holding tokens in a json file on the server accessed through the path status/plugin/json/tokens.
{ "json-plugin": { "35ece947aa90b581": { "id": "demo", "nb": "widely known, discard if abused" } } }
A write would be authorized if the file is present, the slug listed and the token appearing under the slug. Usage stats could be collected under the provided id as a way of distinguishing abusers should there be multiple tokens.
# Resources
REST Best Practices for Concurrent Updates. post
wiki-plugin-json