This is a note to get it off my mind, currently not a requirement that needs to be worked on!
ess.reduce.streaming.StreamProcessor currently takes an all-or-nothing approach to updating and re-computing: It is assumed that all "dynamic inputs" are updated at the same frequency. Then, everything (non-static) is recomputed, accumulated, and final results computed.
In practice, there may be dynamic inputs that change with different frequency (for examples fast detector event data updates alongside slow detector bank move), and we may thus want to reflect this in the way the workflow updates/recomputes. Pre-computation of static inputs may be replaced by a more dynamic mechanism that can handle nodes that updated infrequently (or not at all).
As this is potentially more risky, since it seems to be constituting a potentially more error-prone caching mechanism, I think we should not perform such a change until a clear need is identified.
This is a note to get it off my mind, currently not a requirement that needs to be worked on!
ess.reduce.streaming.StreamProcessorcurrently takes an all-or-nothing approach to updating and re-computing: It is assumed that all "dynamic inputs" are updated at the same frequency. Then, everything (non-static) is recomputed, accumulated, and final results computed.In practice, there may be dynamic inputs that change with different frequency (for examples fast detector event data updates alongside slow detector bank move), and we may thus want to reflect this in the way the workflow updates/recomputes. Pre-computation of static inputs may be replaced by a more dynamic mechanism that can handle nodes that updated infrequently (or not at all).
As this is potentially more risky, since it seems to be constituting a potentially more error-prone caching mechanism, I think we should not perform such a change until a clear need is identified.