- Get an idea about different implementations and how things were implemented and why
- Further use casse and what could be added to the schema specification
- Some answers how to implement it correctly
- Best practices
- Rust server coredump (spaceapi-community + own implementation)
- Client-Server architecture
- Door status and other information (sensors) published into Redis with an expiration period -> automatic open/close mechanism
- Chaos Computer Club Basel Implementation
- Added additional information like stock of different kind of mate
- Door status and other information (sensors) published into InfluxDB
- Cron Job clears open status
- Extra device in space
- Buttons for people arrive/leave
- Counter is displayed via Nixie Tubes
- Fork of the spaceapi-community Rust server by dezentrale
- Simple configuration via yaml file to configuration the long living data (address, website, ...)
- Client-Server architecture
- The API endpoint runs on a VPS
- The client runs on an RaspberryPI and send open/close via an additional not specified admin interface protected by an API-Key
- Next feature Dead man's switch
- Keep alive every 5 minutes to signal the space is open
- If client doesn't call after 5 minutes the server set status to closed
- differentiation between regular open/close request and keep-alive request as business logic
- Python implementation of Chaostreff Potsdam (CCCP)
- Python Flask implementation
- Sensor data from solar power generator is provided
- Open status is directly gathered by the server application
- There is already an externsion pattern
ext_<fieldname>to describe data, that's not specified - Related spaces to express friendship between spaces -> linked spaces already specified for schema specification v15
- Representation of a network of spaces like the ChaosZone (Spaces from East Germany, Czech Republic, ...) -> maybe via an tag
- Solar power generation provided provided by CCCP isn't specified -> CCCP maybe has maybe an open MR as a recommendation for specification