alright time to do this correctly because this is brutal

7/18
DM -> RLC -> RM -> Sys -> TM -> TC
this basic struct will guide us

Work backwards to start from what the TC wants and work to how to deliver

TC
- wants to know what the overall reactor status are and the associated device status on selection
- its OK if this is a bit out of date, but probably want a synchronized view between clients
    - could be a performance hit but f it

TM
Needs to:
- provide up to date information about the reactors connected and know which reactor is selected and provide updates for it
Relies on
- Needs a central struct, 2 methods for data
    - call on request to query for ir
    - keep its own copy and empty its buffer on request
        - this is probably the best route

So TM really needs an intermediate struct a sort of device buffer
- I like the thing we had before with the channels and embedding but it needs to be fleshed out

All of this resides on the server which we can use to our advantage
Lets flesh out the TM a bit more

TM sys struct
this struct will attach itself to a channel and buffer updates for that channel
has to have a few methods
    - GetBuffer() returns any new entries and empties the buffer
    - ListenTo(reactorID) starts listening to a reactor and returns any devices on that branch so the client can refresh its list
    - Refresh() forces the client to get all reactors and devices if listening to any branch
NewSysMonitor() has to return struct and current client status to load fortui client

this client will be given to a TUI at creation

TUI can then call associated commands to get updates for the client

TM sys struct just relies on underlying sys implementation which seems to be working south of the RM so i am just going to work on this TM sys struct for now