You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For interaction with UIs and CLI-based tools, we need a way to send messages into a machine. Not everything is a swingset machine, so we should enable some sort of lower-tech protocol.
I'm thinking the device node should use Node's built-in HTTP server, and the root object should provide a registerHandler function. Each time an HTTP request arrives, the handler will receive a message that includes the full contents of the request as arguments, plus a "response index" or handle of some sort. Calling a second function on the root object with the response index causes the HTTP request to be answered. We can then wrap this in a Vat which does some minimal dispatch/routing, and presents a promise-based interface (so the real target of the message can trigger a response by just fulfilling their response promise to the HTTP response data).
It might also be interesting to add an HTTP client device, but that's lower priority for now.
The text was updated successfully, but these errors were encountered:
0cfc866 adds the "command" device, which is the part that belongs in SwingSet. It gives a way to send commands into a swingset machine, returning a promise for the result. Internally, each command is given a number, and the recipient of the command is responsible for calling D(devices.command).sendResponse(number, value) when that promise ought to be resolved. There's also a broadcast channel which we need for the REPL frontend.
So I think I can close this now. For an example of how the command device should be used to provide an HTTP-based invocation tool, look in cosmic-swingset at lib/ag-solo/web.js and start.js.
For interaction with UIs and CLI-based tools, we need a way to send messages into a machine. Not everything is a swingset machine, so we should enable some sort of lower-tech protocol.
I'm thinking the device node should use Node's built-in HTTP server, and the root object should provide a
registerHandler
function. Each time an HTTP request arrives, the handler will receive a message that includes the full contents of the request as arguments, plus a "response index" or handle of some sort. Calling a second function on the root object with the response index causes the HTTP request to be answered. We can then wrap this in a Vat which does some minimal dispatch/routing, and presents a promise-based interface (so the real target of the message can trigger a response by just fulfilling their response promise to the HTTP response data).It might also be interesting to add an HTTP client device, but that's lower priority for now.
The text was updated successfully, but these errors were encountered: