Last edit
Summary: When asking for some criticism from a colleague today, I got some additional pointers and ideas on my . . .
Added:
> * The slot object (more on that later).
Changed:
< * Sends a signal to the Controller board telling a board has been inserted in a certain slot
< * Can cut the power of a specific slot
to
> * Sends a signal to the Controller board telling a board has been inserted in a certain slot;
> * Can cut the power of a specific slot.
When asking for some criticism from a colleague today, I got some additional pointers and ideas on my design sketch. Some concepts were implicit, but would be more clear when mentioned specifically:
The Controller board will carry state for the equipment that's in the rack, but since a (possibly accidental) power-down of the rack would lose state, the previously mentioned discovery mechanism still has to be created.
The software will also get a lot more simpler if we assume there is some intelligence in the rack. Thus, we can assume that a future rack will perform the following functions:
He also pointed out it's worth thinking about whether we must model the rack functions itself, perhaps as a class called RackDriver. The slots in the rack were previously left out of the model, because they did not have any meaning for the software. This now changes, since we assume the rack has some intelligence.