TODO

All function calls are currently performed anonymously without
authentication, making Snafu suitable primarily for experiments,
prototyping and internal use. Future versions will offer authentication
through 'snafu-control' and perhaps through the web connector as well.

 -> snafu-control part has been solved

Functions implemented in Python 2 and in other programming languages are
currently not supported. This may be changed by the introduction of
external launchers, at the cost of higher call overhead.

 -> external launchers are now available

The isolation level offered with --isolation is weak. A medium-level
protection could be achieved by running snafu slaves in separate
containers with mounted tenant function directories.

 -> proxy and docker executors added

Some clients (notably awscli) close connections and open new ones while
functions are still running without any chance to report back their
results. Snafu would have to clean up the sockets in CLOSE_WAIT state
immediately to avoid hitting the fd limit.

 -> reaper mode implemented, but no mapping yet to running threads

Some rather often used methods are not yet implemented in snafu-control,
notably update-function-*. Likewise, versioning is not yet supported.

 -> update-* is now implemented

Asynchronous invocations are not supported at all at the moment.

 -> there is now an async keyword in interactive mode

The parser code for finding about which functions and parameters are
available is currently monolithically located in snafu.py. Parsers
should become a new subsystem class to ease the addition of new ones and
maintenance of existing ones.

 -> parser code is now available as subsystem, with per-type defaults

There is currently a global default executor which makes it impossible
to execute functions written in different languages within the same
session. Rather, there should be a per-function default executor which
is determined by the function file type.

 -> per-type default executors are now available

Advanced decomposition approaches (Podilizer, Lambada, function
splitting) should be integrated as smart executors.

Snafu-import is in need of some extensions, for instance the export of
functions from Snafu to production systems, and the addition of
OpenWhisk as target system (-s snafu, -t openwhisk).

Apart from Lambda, more call conventions should be added. There is
currently a limited amount of parser support within JavaScript to
distinguish OpenWhisk from Google Cloud Functions. This should be
consistently extended to all APIs implemented in snafu-control and made
available to the -c flag. (For consistency with other subsystems, -c/-C
should also be swapped.)

The JavaScript parser based on PyEsprima does not handle complex
JavaScript code. The Esprima online demo however parses it correctly.
The alternatives (Esprima-Python, PyJSParser) all bail. Therefore, an
alternative implementation is to install and run esprima as separate
process and parse the JSON output to get the exported function names.

To better debug function execution, a tracing executor should be added
for at least the Python language. This executor should output statistics
about local and remote function calls and generally useful information
from the profile module.

 -> a tracing executor is now available in a forked version
 https://github.com/Nopx/snafu

A snafu-deploy tool could be developed to quickly deploy functions to
any cloud provider without going through the hassle of learning the
provider-dependent deployment tools. Execution is then possible through
snafu -X.

A marketplace is needed to host functions. For its implementation, a
passive snafu-control mode which only allows for function management but
not for execution would be suitable.

 -> simple passive mode is now implemented

# Misc:
# better error messages for docker (+ maybe docker also for pure snafu)
# check for oracle functions