schema
schema copied to clipboard
SpaceAPI JSON schema files.
In #106 we made the top-level `location` field optional. If it is defined, the lat/lon fields still need to be defined though. Some virtual spaces might not have a location,...
Since we encountered annoying issues in v14 while implementing it in spaceapi-rs for example I think we should start implementing it at least once before the release. * https://github.com/spaceapi-community/spaceapi-rs/pull/118
The nullability of state.open is documented as deprecated but I couldn't find the rationale. A nullable field is much easier to deal with when generating JSON, because the code for...
For the reason that there are some open MQTT-Servers of Hackerspaces out there, where the spaces publish some informations like door status, temps or sun collection , this section might...
In v15, there should be a way to specify webcams with metadata (e.g. location, description, etc) similar to sensors. Maybe we could add a new field (`webcams`? `cams`? `cameras`?) that...
Since #56 it is possible to provide a sort of compatibility indication server side, but there is no client side preferred version possible. We're looking into migrating to newer SpaceAPI...
The `location.address` field is described as "The postal address of your space (street, block, housenumber, zip code, city, whatever you usually need in your country, and the country itself).". This...
Some dutch hackerspaces (Revspace, TkkrLab, Bitlair) have started providing their spacestate over MQTT, in addition to the spacestate in the spaceapi json file. The added value is that MQTT is...
I would love to see the state of our 3D printers through the api, not sure where exactly to put them in the json, though. Could that be included?
Right now `feeds` is an object with keys `blog`, `wiki`, `calendar` and `flickr`. Issues with this: - There is a mix between generic terms (like "wiki") and a service that...