Replies: 3 comments 7 replies
-
in #60 (comment) Hello, |
Beta Was this translation helpful? Give feedback.
-
Proposal from @runtimevic* We need to describe it in more detail, I have a rough idea of what you mean, however, to narrow down the meaning of those structures I have some questions in italic Components STRUCT: a component will consist of the following structure: ConfigThis seems clear. The structure should contain eventual configuration data for the component Control:What should be in this structure and what is the purpose of its? Status:How should this look like? Some components can have multiple states at once (we have TcoTask to provide some status information) Error:How do we structure Errors (Last error, error history, buffer)? (how would this add to existing messaging (_mime) or is this meant differently (error lists?) Inputs:Outputs:For complex I/O this should this be VAR_IN_OUT? |
Beta Was this translation helpful? Give feedback.
-
Have also look here #75 |
Beta Was this translation helpful? Give feedback.
-
How should the components be structured?
There is some general idea of how the components should look in terms of structure that derives from early discussions.
There is some description in the conventions that needs to be widened.
Some idea about the execution of the tasks is here
Other discussions did run in Slack channel (TAP pattern - async calls of tasks ...)
What we will need to narrow down is the parameter transfer, parameter persistence etc.
Beta Was this translation helpful? Give feedback.
All reactions