accessing the exit nodes
work out how the exit nodes will be accessed in practice.
- the key to access the exit nodes is a Pipe-ID
- the actual exit nodes are available per segment
- consequently the segmentation data structure will host that resolution step
- the segmentation is part of and managed by the Fixture
So the question here is, how to represent this resolution step:
- to which extent is it necessary to expose the participants?
- how can be mock this resolution step for tests?
- how is the builder able to integrate the results of a build process into this mapping?
Change history
(6)
| blocking: |
805, 726, 787 → 726, 787, 805
|
| blocking: |
726, 787, 805 → 726, 787, 805, 875
|
| blocking: |
726, 787, 805, 875 → 726, 787, 805, 875, 894
|
| blocking: |
726, 787, 805, 875, 894 → 726, 787, 805, 875, 894, 1364
|
| blockedby: |
1287
|
| blocking: |
726, 787, 805, 875, 894, 1364
|
| Parent Tickets: |
→ 726, 787, 805, 875, 894, 1364
|
| Sub Tickets: |
→ 1287
|
From reading all my notes and planning from last winter, I conclude that the Dispatcher would be responsible to perform this translation step. But, right now the internal organisation of this Dispatcher isn't clear. We know that we get some sort of dispatch table -- maybe for each CalcStream, or rather for each Feed? Anyhow, this dispatch table is used to translate time -> frame number -> segment -> real exit node.
Initially, it's outfitted from the Segmentation within the Fixture -- theoretically we could even use the Segmentation itself, but this would require locking.