DMAC/notes

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)


TODO 6/27
- Time to tackle sensor managers officially
    - to hell with port generation
    - going to use channels but not like a jackass
        - going to try generating channels interface side but via implicit types to avoid the interface stff
    - should set up a structure where I can use arbiturary types on the backend and fulfill methods to get/infer information on the frontend
- rewrite I2C interface to employ same method, should allow for this 
    1) generate type
    2) send it to worker
    3) receive back (original? copy?) 
    4) use interface methods to get required values 
- should simplify all internal communication and potentially suggests api for implementation