                            remctl To-Do List

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.

Server:

 * 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.

 * Support arguments that are too long for the command line or that
   contain nul characters.  The best approach is probably to support
   passing one of the arguments to the executed command on standard input.
   This may depend on the new configuration syntax.

 * 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.

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

 * Add support for external ACL checking programs.  If the program exits
   with a zero status, access is granted.  If it exits 1, access is not
   granted but checking continues.  If it exits with any other exit
   status, access is not granted and checking aborts.

   Ideally, for writing generic ACL checking programs, the program should
   get the type and service of the remctl command as well as any
   arguments.  However, it would also be good to support passing other
   arguments into the program as specified in the ACL file.

 * Possibly support binding to both the new and the old port in the
   standalone server for backward compatibility (only if requested by
   another flag).

 * Sort the files in a directory before processing them so that the order
   is deterministic.  Affects both configuration (earlier entries
   override later ones) and ACL rules in the presence of deny ACLs.

Client:

 * Implement file upload in the remctl client.

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

 * Support setting a timeout and failing the remctl call if the server
   takes too long to connect or send back data.

 * Add an option that prompts the user, with echo disabled, for a piece of
   secure data, prompting twice to ensure both times match, and then sends
   that as the last argument to the command.  This would be useful for
   remctl interfaces to change passwords.

Build system:

 * Add logic to detect Solaris vs. GNU ld on Solaris and pass the
   appropriate option to use the symbol versioning map file on Solaris as
   well.

 * Incorporate a program that can generate a Kerberos ticket cache from
   a keytab and use that for running the Kerberos tests instead of
   requiring the user to generate a keytab.

 * Add pkgconfig support for libremctl.

Portability layer:

 * Refactor getopt to be easier to understand and less deeply nested.

Windows port:

 * With more modifications, it should be possible to build remctl against
   SSPI, the GSS-API-like interface built into Windows, and remove the
   dependency on MIT Kerberos for Windows.  However, limitations
   surrounding realm trusts in the Kerberos implementation in versions of
   Windows prior to Vista would make this a less general solution.

 * Support the remctl server.

Java implementation:

 * Fix the coding style of the Java implementation to match the coding
   style of the rest of remctl.

 * Consider reorganizing the java directory so that it already matches the
   layout of an Apache Jakarta project rather than having ant tar shuffle
   everything around.

 * Add a JUnit test suite for the Java implementation.

 * Integrate the Java build into the rest of the build system so that it
   is enabled using an --enable-java flag similar to the bindings, finds
   ant and a JAVA_HOME in configure, and does the JAR build in the main
   Makefile using ant.

 * Consider eliminating the simple Makefile in the java directory and
   requiring ant.

 * Java cannot obtain tickets from a ticket cache created using the
   k5.conf file included in the java directory using the current MIT
   Kerberos on Debian.  It has to prompt for a password and get tickets
   itself.  Figure out why and fix it.

Test suite:

 * Combine the documentation tests together rather than testing POD
   separately for server and client.

 * Add spelling check tests for the POD documentation.
