Interactive I/O

Currently, any I/O interactions with the server are entirely static: full input is passed to the compiler, and then this is converted internally into the input stream for the compiled program.

In the real compiler, not passing the --input flag results in a redirection of stdin straight into the process, for an interactive program. It would be nice if the website/CLI could also support this interaction. This would likely involve Websockets to establish real-time bi-directional communication between the server and the client. This is at least somewhat challenging:

1. We don't want to duplicate the logic for a flat compile (and run) vs an interactive compile and run
2. We don't want to use Websockets for every request
3. We may not have streaming support on the current server implementation with the JDK HTTP Server.
4. For the web interface, we need an interactive console (see later).

With the exception of (3), which is more challenging to resolve and requires investigation, (1) and (2) might be addressed as follows:

• When the server receives an interactive emulation request (let's suppose input: Option[String] == None) then it avoids the temporary folder deletion, and also augments its response with the temp folder's unique name (should the prefix include the requester's IP/identity somehow to avoid possible clashes?).
• The client, who requested the interactive response, receives the compilation contents, which can be printed accordingly, and a second Websocket request is made to interact with the folder.
• The two then communicate happily with separate execution logic: every time the executable pauses for input, all its output could be bundled up and sent back as a response to the client.

Representing the Interaction

In both the CLI and the website, we need some way of showing how the interaction is proceeding. Ideally, these aren't kept separate. For the CLI, it seems easy enough to just print to the console as normal, and the input prompts will be inline; the website, on the other hand, is more complex:

• We want a text-area that is pinned to the result of the I/O: whenever enter is pressed, we need to send this off for processing.
• It would be good (including for batch-mode), to highlight the input passed where it appears -- for batch this is harder, since we need to know when that input was consumed by the process.