DMAC/notes.md

*Time for a coherent plan of attack*

### Current Issues:
- There is a lot of redundancy between the managers/coordinators when it comes to basic checks
- the package seperation kind of makes sense, but it needs to be better fleshed out
- I need to enforce better seperation of responsibilities. Somewhat unclear when state is being kept centrally in the coordinator for no apparent reason.

### Solution:
- Go through the packages and consolidate
- Reduce the state we have to keep centrally, push responsibility to the other packages

### Plan of attack:
- Outline core information flow
- Examine what interfaces are nessecary to make this work
- Stop looking at the server/reactor as seperate entities

*I need to put the whole docker thing on the back burner for now. It isn't that important when it comes to immediate goals.*

#### 12/05 TODO
- Cleanup server side config stuff to make it coherent
- Reflect changes to reactor side startup
- Boil down interface to address core issues
- Config outline:
    1) Startup and load the existing config
    2) Overwrite any previous settings with the flags
    3) Intelligently translate config into action
    4) launch coordinator and start up existing reactor managers
- Config Structure:
    - Wrap viper functions in config struct methods to be used thrtugh interfaces
    - minimize the reliance on viper so we can sub in othermethods
- is it even important to launch reactor managers? Wont they just be started on connection?


#### 12/06 TODO
- I think I can completely remove the old config way and just pass the viper object directly. I think its not worth the hassle of trying to keep track of a million interfaces

#### 12/07 TODO
- I concede, I will just remove flags as most people will never use them anyway and instead rely on env vars and config files. To hell with the flags.
- I am ripping out all of the TUI and status manager stuff, its convoluted and harder than just pulling info from database.
    - I can eventaully rework TUI to pull from DB which is fine, there will never be that many clients anyway and a lot of them are only 1 time calls with refreshes which aren't that slow anyway.