This repository has been archived by the owner on Mar 24, 2023. It is now read-only.
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.
What I Did
Move some Daemon interface methods into a
StatusReceiver
interface, to be used for V2, replace Planner & RendererDaemon
field with this narrower interface.
I played with a few other approaches to this, like taking the type
doWithProgress func(chan interface{}, log.Logger)
andtrying to pull that up the call stack as a parameter, but I think narrowing the daemon interface is going to be the quickest path
to victory.
I imagine once
statusonly.StatusReceiver
is done implementingdaemontypes.StatusReceiver
or something.
How I Did it
func() Planner
instead of aPlanner
, this will let us create an instance per request and set its StatusReceiver (Renderer
will probably need this too, but its not done yet)state.State
interface that is superfluous now that we havestate.State#Versioned()
How to verify it
All refactoring here still, this stuff has pretty decent coverage so far.