... | ... | @@ -39,3 +39,14 @@ Proposed Design |
|
|
* This singleton is responsible for the execution of Operators as well as providing status back from asynchronous Operators.
|
|
|
* Operators would be registered with the manager
|
|
|
* This manager would be able to indicate the current status of defined operations
|
|
|
|
|
|
|
|
|
|
|
|
# Comments 07-Jul-2016 (john)
|
|
|
I don't have any hands-on with operators, but for what it's worth:
|
|
|
|
|
|
* I would vote to make operators independent of sessions. If instead operators require sessions in some way, then we should refactor that functionality into a separate operator context or runtime class.
|
|
|
* We should also plan on future operators that use resources from multiple/different modeling kernels at the same time and, by inference, work with multiple sessions concurrently.
|
|
|
* As more/future operators will be carried out remotely using REMUS or cumulus, we should plan on separating the operator template into separate functional and platform/endpoint specifications.
|
|
|
|
|
|
|