Closed croissanne closed 6 years ago
Another option is to split it up in 2.
A pluginrunner responsible for starting the study.
An ApexModule responsible for committing the results and maybe adding some study-specific xml to the apr. This will require some modifications to the RunDelegate though.
There is already a ResultSink module, it could be made study-aware, but that would mean that the study concept appears in multiple places throughout APEX. This is not necessarily bad, but will result in quite a number of changes, I think.
Well I meant a separate module. A StudyModule that tries to commit results etc when the experiment is finished. We'd also have a place to put study-specific result xml if needed.
That's part of what resultsink does now, isn't it? Anyway, let's discuss IRL, that's more efficient
So to decouple apexcontrol and studymanager it would be best to have the latter as a runner.
Preferably a pluginrunner, however the pluginrunners are implemented as modal dialogs which only give a filepath to open and then get destroyed. The studymanager needs to be able to handle results after the experiment is done. In other words it needs to persist the experiment. This requires some restructuring of the pluginrunner to make it behave more like the other ExperimentRunners. For now we only have the spinrunner as a plugin.
Or we can implement it as an ExperimentRunner (not as plugin) in apexmain since those persist until after the experiment. However I think it might be best to avoid this since we already special cased the flowrunner in this way and it resulted in bloating of simplerunner.