dispatcher needs option to queue job but also observe log

this could perhaps be done by having the client side also tail (and parse) the log file that is produced by the server

What about when you're running the command line tools from a different box? (This is possible if you just configure framework.properties the right way.)

But that would assume bi-directional communication on the remote machine?

if you use CLI tool or web API to run jobs/adhoc commands from a different
client, then it would require some new api ability to tail log output
remotely...

Well, how does the output get to the web page? It's an AJAX call to refresh the latest log output, right? Why can't the CLI tool also use the same call? (This would require a polling from the client, though, which I don't like.)

Alternatively, to make it more realtime, you could just have a fairly simple API request that would just return the log in Transfer-Encoding: chunked form as RunDeck receives it. We should be able to unescape that and output it immediately to the terminal.

(In general, I think our goal should be to allow someone to never use the GUI-- they should be able to use all of RunDeck's primary functionality just from the command line or the web service API.)

the new api ability would use the same underlying code. the ajax/json used
by the gui is not documented as an api.

the gui polls for new data. That is the simplest way to do this for the api.

if you want more realtime output, this requires the server to keep
connection open and the thread running

At some point yeah. Given the request/response nature of the webui, you'd have to have a way of changing to some stream mechanism, i.e. websockets. All in due time :)

Aren't we thinking a little too complicated here? We don't need bi-di or websockets... I would imagine it would work like this:

Client sends GET or POST with these items: execution ID and either 1) log line to start from or 2) timestamp to start from, or indicate it should receive the log starting from "now". At that point the client doesn't need to do anything else; if it loses the connection it just needs to re-request from the last content it got. (Could possibly use HTTP Content-Range headers for this.)

At that point the server just needs to send a response (probably text/plain in the same format that logs are written to disk), keep the thread open and not close it until Success or Failure or other job ending event. At the end of the output, server should send a trailer header field with the Success/Failure/Killed status of the job and then close the connection.

If the client asks for the live log, but the job has already completed, server should return the output from where the client requested it, send the trailer header, and close the connection.

I don't think polling for latest data on interval would really be acceptable at the command line-- the experience should be equivalent to your executing "ssh server command"; i.e. the expectation would be that the output would come back in real time. In other words, the experience should be the same as using --noqueue, but with the execution logged on the server.

(As a matter of fact I don't think the polling is really that great for the web UI either, but the expectations for a web interface are different from the expectations for a command line tool, so it's more acceptable there. One way I can think of off the top of my head to accomplish realtime output for the Web UI would be to do the same thing as above, but have the client request the log in an , which could be kept in a loading state until the job is done.)

Are the log files kept on disk updated in close-to-realtime? If so, we could accomplish this just by sending a redirect to the log file location, and HTTP could accomplish this for us.

but have the client request the log in an <iframe>