Add complete traceability description/example when using Eiffel Intelligence
Opened this issue · 2 comments
Description
Traceability is perhaps the cornerstone of Eiffel. In practice, this is done by using appropriate event types and appropriate links between such events.
Motivation
Eiffel Intelligence muddies the water by having subscriptions performing REST-calls instead of publishing events. Granted, the REST-call could be to REMREM and so publish an event - but what type, contents and links should be used and how is the required information available in EI?
Most of the information around EI is based on the mutating the object and trigger subscriptions when some specific state has been reached. There is very little information on traceability aspect.
Exemplification
The core idea in EI is to have objects that mutate over time, based on events.
- How is traceability to all events that has lead to the current state captured?
- How can the traceability chain to those be kept when a subscription is triggered and the REST-call is done be kept intact?
Benefits
A better understanding of how to keep the traceability chain intact.
Possibly - in the worst case - also a realization that a change is needed in EI to handle full traceability.
Possible Drawbacks
None
I completely agree that EI should provide means to keep the traceability aspects by enabling events to be chained. And as far as I understand that is perfectly possible in EI today.
But, I don't see how this is an issue on the Eiffel Protocol. As I understand it you're requesting proper documentation for EI showing how the traceability aspects of Eiffel are kept through its aggregated objects and subscriptions. If that is a correct understanding, please raise this issue in the Eiffel Intelligence repository instead. If not, please clarify what you would like to be done in this Eiffel Protocol repository.
This issue was moved from the Eiffel protocol repo since it is solely about EI.