Compare +mute and +mule. Those pass through scry, which doesn't allow us to
catch crashes due to blocking scry. If you intercept scry, you can't preserve
the type polymorphically. By monomorphizing, we are able to do so safely.
This broke when %kick was handled by resubscribing on your own ship
because it processed the %kick before the %leave. For example, `@t`404
at the dojo would put the dojo in an unworkable state.
You want the %leave to be processed first because you can't do a
"resubscribe" in response to that.
This adds syntax for running imps. For example:
-time ~s1
Runs the "time" imp with the argument ~s1. This blocks the terminal
until the imp has completed (backspace kills it, of course). You could
avoid blocking the terminal if you sacrifice the ability to use imps as
sources in more complex commands.
In keeping with this one-and-done view of imps, this also changes spider
to not use a live build of imps. This significantly reduces the amount
of uncertainty around imps -- spider will try exactly once to run your
imp, and if it fails it'll tell you. If you want to retry, that's up to
you.
This removes the %http-response special case from gall. In its place,
we implement a subscription regime with the following steps:
- Agent sends %connect to Eyre
- Eyre pokes agent with %handle-http-response, including unique eyre-id
- Agent passes %start-watching to Eyre with eyre-id and unique app-id
- Eyre subscribes to agent on /http-response/app-id
- Agent produces a %http-response-header fact followed by 0 or more
%http-response-data facts and possibly a %http-response-cancel fact
- Agent produces a %kick to close the subscription, which Eyre
interprets as completion of the message.
This works when there is data. There is currently a bug where if the
response has no data in total (as in the case of a naked 404), no
response will be sent.
This also includes lib/http-handler, which implements a convenient
interface for agents that want to respond immediately with all the data.
This lets them avoid carrying extra state to keep track of pending
requests.
This should really have access to your state and the ability to change
it. Perhaps a more minimalist design would be better: just keep track
of the requests, then hand it off to +on-watch when eyre is ready to
receive responses. It's not clear how to pass in the request data in
+on-watch.
For some reason Jael subscriptions aren't starting properly for many
people. Until we can get to the bottom of it, this sets everyone to
start listening directly to the chain.
We were updating our state and then using that when checking if the rift
had incremented. This would never be true, since we'd already set the
new state.
Fixes#1852 again
