the initial draft of this concept is in place now, and
the first round of unit tests pass. I've got some understanding
of the purpose of the interactions and involved elements
and I'm confident this design is evolving in a sane way.
Note: extensive documentation is in the TiddlyWiki,
here I've just pasted and reworded some paragraphs from there
and integrated them into the Doxygen docs
the "log joining" functionality was already implemented
and covered with the generic event log facility, but this test
here was drafted even before that, meaning that the semantics
of matchingn on the log, especially on events, as been
implemented slightly different than planned
since, by definition, the Nexus is "the" up-link,
all we need is clever overriding of the relevant
handling functions, so the nexus will care for the routing,
while the CoreService cares for command and presentation
state handling
I think it is a shame to waste the nice name "nexus"
just for a test facility; rather I've named our central
routing hub in the UI-Bus gui::ctrl::Nexus
So it makes sense to name the fake for unit testing
the test-nexus (we're not at nexus 5 yet)
...providing the standard implementation of UI-Bus connectivity.
It seems reasonable to place all of the UI-Bus implementation into
a single translation unit
