Wed Sep 19 15:50:01 EDT 2018
Presentation models and the unit machine.
There is a concept from mechanics called the "unit machine". It is a
collection of parts that interact in a way that requires very tight
coordination. Basically, the entire machine is one coordinate space
where there are strong constraints between the coordinates. Think of
an interference engine, where pistons take turn to occupy space. When
the timing belt breaks, this constraint is lost and pistons can crash
into each other.
Basically, when composing sub-machines into larger machines, a
decision needs to be made about modularity: do the machines interlock,
or are they largely independent?
A same trade-off appears in gui (panel) design. Generally,
constraints can be solved by using a presentation model:
- Some arbitrary state gets updated by events
- A new presentation model gets generated for each update
- The diff of the presentation model is used to generate change commands
Now suppose I want to put two gui widgets on one panel (web page).
The choice is then to interlock them, i.e. create a single
presentation model, or to keep them fully independent.
Here "independent" means that there are no circular control
dependencies. Bascially, a change in one control cannot change
EDIT: I think the underlying idea is valid. As usual, it is not
exposed very well here.
The basic architecture revolves around two kinds of hubs:
- A global status hub
- Some smaller, localized hubs, e.g. PMs for guis
input -> controller
controller -> distributed models
distributed models -> status_hub
status_hub -> controller
controller -> display
drawing this, here are some possible signal flow paths:
input -> controller -> display
input -> controller -> model -> status -> controller -> display
model -> status -> controller -> display
modelA -> status -> modelB
Note that it is still possible to have model -> status -> model loops,
so maybe it is a good idea to formalize the event dependency path?