From 835e5737cc99ec2882b6fd87a40a7cfff7f92578 Mon Sep 17 00:00:00 2001
From: Martin Hierholzer <martin.hierholzer@desy.de>
Date: Fri, 28 Feb 2020 14:55:00 +0100
Subject: [PATCH] wip #120: added one comment

---
 doc/spec_initialValuePropagation.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/spec_initialValuePropagation.md b/doc/spec_initialValuePropagation.md
index 7adade34..3e88ebb7 100644
--- a/doc/spec_initialValuePropagation.md
+++ b/doc/spec_initialValuePropagation.md
@@ -22,7 +22,7 @@ This specification goes beyond ApplicationCore. It has impact on other ChimeraTK
 
 ## Detailed requirements ##
 
-1. All `ChimeraTK::NDRegisterAccessor` implementations (including but not limited to the `ChimeraTK::ProcessArray`) must have the `ChimeraTK::DataValidity::faulty` flag set after construction for the receiving end. This ensures, all data is marked as `faulty` as long as no sensible initial values have been propagated. The sending end must have `ChimeraTK::DataValidity::ok`, so that the first written data automatically propagates the ok state. [TBD: What about bidirectional variables?]
+1. All `ChimeraTK::NDRegisterAccessor` implementations (including but not limited to the `ChimeraTK::ProcessArray`) must have the `ChimeraTK::DataValidity::faulty` flag set after construction for the receiving end. This ensures, all data is marked as `faulty` as long as no sensible initial values have been propagated. The sending end must have `ChimeraTK::DataValidity::ok`, so that the first written data automatically propagates the ok state. [TBD: What about bidirectional variables? -> ideally change NDRegisterAccessor interface to allow separate validities for sending and receiving...]
 2. All `ChimeraTK::NDRegisterAccessor` implementations must have initially a `ChimeraTK::VersionNumber` constructed with a `nullptr`, which allows to check whether this variable is still at its "first value" or the initial value propagation already took place.
 3. All `ChimeraTK::ApplicationModule`s and similar entities (like `ChimeraTK::ThreadedFanOut` and `ChimeraTK::TriggerFanOut`), that store a `ChimeraTK::DataValidity` directly or indirectly e.g. in form af a counter, must have their internal `DataValidity` flag set to `ok` after construction.
 4. The initial `ChimeraTK::DataValidity::faulty` flags must not be propagated actively. The first propagated data must be always `ok` and must have a valid value.
-- 
GitLab