WardCunningham
commented
4 years ago Some more thoughts on Step.
The computation can be stopped because it has not started or because it was stopped mid run. The client will offer to start in either case. One could start and stop in rapid sequence but our back-end offers a better alternative, step. I suggest this be invoked as shift-start. The server then resumes the computation and simultaneously sets running=false so computation is sure to stop at the next
await step("where I am at")The client-server interaction is interesting in this case. The server can hold up the response until the next step is reached. In the cases we imagine this will be within seconds. The start button will show waiting and be deselected until the step completes at which point the computation will cease running and the button will show start.
An interesting case is when the computation does not reach a step in a timely way. I propose that the waiting continue for maybe 10 seconds. The the server could then return a result that somehow shows that the next step has not been reached. If might just set running=true (it is running) and reply with whatever status it has.
The user's interpretation in this case would be that a shift-start which was meant to step became an ordinary start. At this point the developer could kill -9 the server and insert more step calls into the computation.
joshuabenuck
The client-side is not quite right yet.
Here we replace the client with a script that hits the server three different ways with curl commands.
This script runs a new command every two seconds. The behavior server-side depends what action sequence the script chooses. The script runs in three phases: