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.
2.1 KiB
2.1 KiB
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:
- Startup and load the existing config
- Overwrite any previous settings with the flags
- Intelligently translate config into action
- 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.