Now that I have a better understanding of the system and its limits, I suggest dumping the C++ REST service and its Pistache requirement - those services steal precious resources from a system that should have other priorities. Instead, I would like to propose a VERY slim solution with five main components that are more "secure":
- cron daemon that calls the **bash service** at regular intervals
- **bash service** that reads / writes to a **status cache** and can be used by all system files. It should also serve to protect the system from malformed commands, act as a cache-locking mechanism and also enable locking the interface to one user.
- **status cache** file that exists on a file-system reserved chunk of ram / or **fifo** - something like /tmp/status.json
- netcat GET (:80) / POST (:8080) endpoints (see below for what I mean)
- offline-first fullscreen web interface (hosted at apertus.org that allows the user to choose a password and local IP address to route its requests to) - can later be recycled for native apps
Here are some starting points for what I mean about using netcat:
```
# one way to do this
while true; do { echo -e 'HTTP/1.1 200 OK\r\n'; cat /tmp/status.json; } | nc -l 80; done
# another way
nc -q 1 -w 5 -v -l -p 80 < /tmp/status.json
```
https://stackoverflow.com/questions/16640054/minimal-web-server-using-netcat
http://www.commandlinefu.com/commands/view/870/sharing-file-through-http-80-port
http://www.commandlinefu.com/commands/view/9164/one-command-line-web-server-on-port-80-using-nc-netcat