Very important to grab error output as well.

Tests? What tests?

As it stands, any code executed will have access to the parent's @inc. It would be preferable to provide an option of either

• Using a default, safely curated @inc so that users could have access to basic Perl modules useful for instruction, or
• Using a custom one pointing to a distinct package tree.

In the first case, packages are simply blocked unless they're on the small whitelist. In the second case, if you want to install cool modules for users and accept risks, you could provide such a thing.

Oyster should react correctly to the appropriate signals and behave like a proper daemon.

Fix it.

There should be a way for one to report on the status of a child process to the controller (ie, whatever is on the other side of Redis).

Suggested Solution: Any message which comes out of channel jobid:out which is prefixed with the job id is to be interpreted as meta information, not actual program output. Thus, we reuse the same channel already open.

We need a way to reconnect a Redis handle automatically so the app doesn't freeze after inactivity.

One cannot stop or pause a running program; one must refresh the browser to refresh the session. We can do better.

The current version, while a WIP, is hideously insecure. open(), fork(), and various other primitives need to be changed to return "undef" for now.

Maybe the same techniques employed for STDIN/STDOUT redirection can be used to "nerf" dangerous functions.

One cannot set the Redis connection in Redis::MessageQueue. Part of the power of Redis is that you can have a cluster elsewhere and then connect to it.