You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
34 lines
1.4 KiB
Markdown
34 lines
1.4 KiB
Markdown
*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?
|
|
|
|
|