Dependency Specification

Dependencies for Automatons need to cover multistaging.

Let's just consider 2 stages. Static dependencies, and dynamic dependencies.

Static dependencies represent Automatons that are required to be live before the current Automaton is instantiated.

Dynamic dependencies represent Automatons that can be instantiated after the current Automaton is instantiated. If these dependencies aren't fulfilled, the current Automaton can be instantiated, but is not ready to accept requests from external sources.

Consider that most programs are structured in this way:

setup();
while True:
   // listen of events

During setup(); is when the program may contact remote services. Any remote service here would be considered a static dependency.

Afterwards in its event loop, any remote service contacted here would be considered a dynamic service.

These 2 stages are just the most obvious. There's no need to only consider 2 stages, there can be even more stages of dependencies. Even some dependencies are only required if the code path hits a certain branch. This would cover things like optional dependencies. However since Automatons are blackboxes, we cannot introspect the branches that the code may take, so we just have to consider the dependencies that the Automaton requires before launching, and the dependencies that the Automaton requires before it can receive requests.

We can use some sort of prefix qualifier that qualifies the dependency as one or the other. Maybe there is a more extensible representation?

MatrixAI / Architect

Dependency Specification #11