time to plan

terms

RLC - reactor level coordinator (Beagleboard)
RH - Reactor Handler (goroutine)
SH - sensor handler (gourtine)
Reactor Side:

needs
    - way to discover active sensors
    - spin up goroutine for each sensor responsible for keeping status and logs
    - way to read back and truncate logs for safe data delivery to servr
    - routing requests from reactor level coordinator to relevant sensor
    - internal memory sharing and channels for reactor level coordination
    
thoughts
    - maybe the RLC can be responsible for packaging data for coordinator response
        adv:
        - clears up the network
        - simplifies pinging
        - keeps the data aributrary
        cons:
        - unknown data size
        - how to coordinate data structure

Server Side:

needs 
    - way to look into a config file for active reactors
    - should then spin up a goroutine for each reactor
        - responsible for recovery and consistent communication
        - individual database entries
        - API?
        - use gRPC for comms between server and BB
    - each reactor handler needs mechanism for pinging, recovery, and database correctness
    - 

message PingRequest {
    // do we even need anything in a ping request?
}

message PingResponse {
    repeated Sensor sensor = 1;
}

message Sensor {
    string type = 1;
    bool status = 2;
    byte data = 3;
}

sensors := [string]q