Matching composition & runtime flows/flow-details

Registered by Joshua Harlow on 2014-08-23

Currently we have an API that allows for *named* flow patterns to be nested inside other flow *named* patterns. When that accumulated unit is ran it then gets flattened into a single structure and then ran with a *single* flow-detail (and composed other atom-details) instead of running with N flow-details (one for each *named* nesting level). This single flow-detail corresponds to the the top most named flow (aka the root), thus meaning we discard the contained other N-1 flow details that could be used as well.

One option/idea to make this less confusing would be that we would enforce and validate that all nested flow patterns were instead of a anonymous pattern type (aka, no name is possible) so that this is clear to the user of taskflow when constructing and running that there will be only a *single* flow-detail that will actually be used during running (the root must be named).

Another option is to fix the current API and create N flow-details (and at runtime use the atoms *parent* associated flow-detail when saving and reading state/results...), this option IMHO better matches the structure that was created at pattern and atom composition time but it does introduce more complexity around reading, writing and associated atomicity of those operations...

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Joshua Harlow
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.