                            remctl To-Do List

 * Allow a more expressive configuration syntax that can set more options
   per command.  Among the things we want to configure (besides the
   logmask configuration we already have) are changing users before
   running the command, specifying an argument to pass on standard input
   (see below), or supporting things like LDAP ACLs.

 * Implement file upload in the remctl client.  On the server side, since
   we want to handle file data that contains nul characters, we'll also
   need to support passing one of the arguments to the executed command on
   standard input.  This may depend on the new configuration syntax.

   The best way to implement this may be to pass only the service on the
   command line and pass all other parameters on standard input, using
   counted strings or some similar encoding protocol.

 * Add support for running commands as filters, passing standard input
   asynchronously from the client.  This requires significant
   re-engineering of the client loop and should wait for better
   configuration since we don't want to do this with every command.  It
   also introduces out-of-order responses and possible deadlocks to the
   protocol, which is disturbing.

 * Maximum argument count and maximum data size in MESSAGE_COMMAND should
   be configurable parameters of the server rather than hard-coded
   values.  This may need to wait for better configuration parsing.

 * Implement Perl bindings for the remctl client library.

 * Support LDAP-based ACLs in addition to file system ACLs.

 * The port that remctld uses is rather stupid and frequently blocked due
   to Windows viruses and other issues.  We need to transition to a new
   port, and hopefully one that's registered with IANA.

 * Add readline support to the remctl client for multiple commands to the
   same server in the same authenticated session.

 * In standalone mode, remctld doesn't shut down cleanly after a signal
   and in particular doesn't delete its PID file if it was configured to
   write one.

 * In standalone mode, we need to fork a new process for each incoming
   connection since the connections may be long-lived.
