You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're adding new commands to WA on a fairly regular basis, and it now being used in multiple "modes". While the run command is still very much at the core of it, we want to make it easier for parts of the framework to be used outside of the normal execution flow.
Most plugin callbacks will take a context, which is currently an instance of ExecutionContext, as an argument. ExecutionContext is, by its nature, rather complex, has non-trivial requirements to create, and is very much tied into the execution flow. This makes it awkward to create outside a normal run. process command illustrates why that is an issue. It creates a "LightContext" in order to be able to pass it to the output processors.
There are two major causer for this:
ExecutionContext serves two very different clients: the execution framework, and plugins. The functionality it exposes to each is largely orthogonal. In the long term, it might make sense to split into two distinct objects, however that will be a very intrusive change.
ExcutionContext is used in multiple distinct, ahem, contexts: Target connection by be present or absent (e.g. process command); output directory may be present or absent (e.g. record command).
In order to make it easier to use plugins outside of the execution engine in the future, we should create a generic Context that ExecutionContext will derive from (and as mentioned above, in the long term, might become a distinct entity containing a Context). The base Context will expose the interface required by current plugins, but not the framework. There may then be additional implementations of this interface, e.g. those that rely on target/output directory, and those that don't.
The text was updated successfully, but these errors were encountered:
We're adding new commands to WA on a fairly regular basis, and it now being used in multiple "modes". While the
run
command is still very much at the core of it, we want to make it easier for parts of the framework to be used outside of the normal execution flow.Most plugin callbacks will take a
context
, which is currently an instance ofExecutionContext
, as an argument.ExecutionContext
is, by its nature, rather complex, has non-trivial requirements to create, and is very much tied into the execution flow. This makes it awkward to create outside a normal run.process
command illustrates why that is an issue. It creates a "LightContext" in order to be able to pass it to the output processors.There are two major causer for this:
ExecutionContext
serves two very different clients: the execution framework, and plugins. The functionality it exposes to each is largely orthogonal. In the long term, it might make sense to split into two distinct objects, however that will be a very intrusive change.ExcutionContext
is used in multiple distinct, ahem, contexts: Target connection by be present or absent (e.g.process
command); output directory may be present or absent (e.g.record
command).In order to make it easier to use plugins outside of the execution engine in the future, we should create a generic
Context
thatExecutionContext
will derive from (and as mentioned above, in the long term, might become a distinct entity containing aContext
). The baseContext
will expose the interface required by current plugins, but not the framework. There may then be additional implementations of this interface, e.g. those that rely on target/output directory, and those that don't.The text was updated successfully, but these errors were encountered: