orenra / test Goto Github PK

The high level requirement, as stated in the email by Alex:
a RESTful API for a cheap clojure "job" mechanism. Users can
submit a job, which contains some arbitrary clojure code, which we
assume is from a trusted user and will terminate. The user needs to
be able to check the status of the job and get the results when done.

To elaborate on this, the task should listen on a configurable port and be able to receive the following http request:

1. An HTTP POST verb, targeting a specific fixed uri like /run-code.
2. An http Content-Type header with the value "text/plain" or "text/html" (tbd).
3. A request body containing the following text:

• An arbitrary clojure code, including, e.g. function and variable definitions, as well as an s-expression that will need to be evaluated. The s-expression possibly utilizing the functions and vars defined.
• Optional: a list of dependencies, specifying packages 'used' or 'required' by the code above. Each dependency will specify a clojure or java package that resides either in clojars or the maven depot, or user-specified repository/s, and include a specific version. If no dependencies are needed by the code (i.e. no require, use or import forms), the list can be omitted. It is recommended to format the deps in the same way as in project.clj.

Upon receiving the request (consider the ring package or some equivalent for that), the server will do the following:

1. Resolve all dependencies, possibly importing packages from external repositories, such as clojars or the main maven depot. If the dependency package is not found, short-circuit with "File Not Found" http code and message. For example on how to deal with dependencies, see the deps function in the lein-exec github project
2. To avoid the usual gotchas, the external code should be wrapped in the following middleware code:

• try-catch to deal with exceptions
• rebind out and err file descriptors to local vars (clojure functions utilize out by default, but they might invoke java code that can make use of err)
• We should try to isolate the code, e.g. in a separate thread, or a go async block - tbd. If we do this, we can also set a timeout timer, in case the executed code simply disappears. Note that ring is not really compatible with the core.async approach, so a different framework might be needed for that.
• pretty-print the result to a string (we may get numeric or structured result).
• Execute the resulting wrapped code (either eval it or compile + run).

p.s. In the try-catch, catch Exception first, as it might have a meaningful exception message. Then Throwable. In the latter case, no message is available, and we'll have to output some general wording like 'unexpected error...", "whoa something broke" or similar.

The response should set the usual http status values - 200 for success (i.e. no exceptions), 400 for exceptions, 500 if no response after timeout (if we're not sure it's the clients fault, we blame ourselves :).
In the body, include the original script, the http status code and message, the pretty-printed output, as well as any strings from out and err bound strings. Each of these under its own sub-title. E.g. "Script", "Status", "Output", "Console Messages".

Did I miss anything? Please feel free to edit and add whatever is missing (or delete the completely unnecessary parts).