Details
-
Task
-
Status: In Progress
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
-
Sprint 3, Sprint 7 Plugin Imports
Description
This is a followup to ARIA-174.
1) Let's move the module to aria/topology from aria/orchestrator/topology. The module in fact is not related to orchestration, and many use cases for ARIA involve using parser+topology but not orchestration. This will produce a clean divide of ARIA's three major components: parser, topology manager, and workflow engine (orchestrator).
2) There are still parts of topology that exist in aria/parser, namely the consumers. We need to think here if we still want to keep the consumer API. If so, it should move to a more general location, so that both aria/parser and aria/topology would use the same API. That way all the parsing-related consumers will be in aria/parser and all the instantiation ones will be in aria/topology. Related to this, I see that currently we are creating a Topology instance for each consumer! There should be a shared one, perhaps sitting on a context. Thus, it may be worth looking at the relationship between consumers and context – parser and topology would each have their own special contexts, although they would share a validation report mechanism (in a contained validation context?).
3) Merge tests/instantiation into a new tests/topology.
4) Create a ReST documentation page for the topology module and test the documentation.,