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
    
6/23 TODO:

X- BBB mem fix
    - 32 gig for the main but where to put the OS?
        - obv in EMMC but how to init sd card? (probably dev tree :( )
Y- Server side impl
   Y - Need a struct for the RC
       X - Should we store and load configs based on IDs? (efficiency of this vs performance increases i.e. bandwidth vs storage)
   Y/X - Who should kill the RC and how do we know its dead? (Garbage collection to the rescue hopefully)
    
X- UPDATE PRES
    - Add bottle necks for each part in that section
        - I2C: 128 addrs and ~90 bytes/s per device at 128 devs optimally
        - BB: Hardware is upgradeable even customizable ;) 
        - Server: Its overkill as is, can benchmark with a rudementary go overload once its completed
- Sensor configs
    - how to store sensor info efficiently and searchably lol
        - who needs to know what the sensor is? (Just the SM? Even the SM?)
X- TUI
    - pls this would be so sick
TODO: 6-24

Y - Pres stuff from yesterday + python gRPC abstraction
Y - RPI flash
- Add resiliance to coordinator process (aka error handley blech)