Closed Krymnos closed 6 years ago
Another Possible use cases of this system could be. Fault Tolerance and Guarantee/Continuous Delivery: In this case, we expect to have a real-time or near real-time analysis system at the end of the pipeline, we consider the whole system to be fault tolerant and being able to recover from a node/gateway failure in the different stages of the pipeline. Our goal is to propagate the data and recover from node failures using the provenance data stored before in near real-time. For every real-time analysis system, continuous delivery of data is crucial to computing some-sort of prediction for making higher level decisions.
I got this feedback from dominik the other day:
its obviously good to have a document in which you capture your motivation/use-cases/requirements. However, it's up to you how specific you feel you need to be. For example, consider the two approaches: specifying concrete latency requirements OR focusing on latency as a core metric, because the lower it is the better you can support certain types of applications. Your overall approach should also be consistent to the document: if you claim to focus on low latency, I would expect (in later documents) an actual evaluation and optimization of your prototype for latency, supported by suitable design and system choices.
Concerning his example I don't think specifying concrete (latency) requirements is possible yet since the types of applications we want to support is so far quite general. However, we already found good reasons for our our motivation to focus on performance measured with storage need and latency as our key metrics, because:
In the first Requirements Document