Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Do Not Merge
I'm creating a PR so this attempt at #684 can be see by everyone, but I'm starting another PR, which will split the engine into only two parts rather than three. For the current PR, I'd like it if team members would take a look and confirm my view that this is a dead end.
It's probably best to follow along by looking at one commit at a time.
Why a dead end?
I think the idea, as described in #684, of having an upper (client) engine, a lower (agent) piece and a common core on which they both depend is a good one. It would probably work well if we were starting from scratch.
What I've seen here, particularly in the last commit of this PR, is that there is so much interdependency between services and runners that the three-part division, while probably possible, would be extremely messy and confusing. All three assemblies end up with both runners and services and it will most likely be unclear to later devs why a particular assembly is used for one class while a different one is used for another. It's probably hard enough to grok it with two assemblies!
If folks look at this and decide it's not as bad as I think and want me to continue with it I will. Meanwhile, I'm going to redo the whole thing in the same steps, but using only two assemblies as I did in the original spike.