supervisor/TODO.txt

- Supervisorctl tab completion and history.

- Supervisorctl "debug" command (communicate with a process over its stdin).

- Allow effective user to switch to a particular group instead of
  defaulting to the user's primary group:
  http://www.plope.com/software/collector/233.

- Allow sockchown group only: http://www.plope.com/software/collector/214

- Implement event max_retry counter that means "after X retries of a
  rejected event, go into FATAL state".

- FATAL state for supervisor.

   - When we try to clear the main log file and we get an IOError or an
     OSError (clearLog)

   - When we attempt to remove a process log file via os.remove (or
     equivalent all into handlers) and we get an IOError or an OSError
     (clearProcessLog)

   - When we try to kill a process and the os.kill command raises an
     exception (stopProcess)

- Generalize eventlistener request/response protocol (wrap OK/FAIL in
  RESULT envelope) so we can use it for more specialized
  communications, e.g.:

  The listener would return 'RESULT %s\n%s' (len(result), result).
  For event listeners, the "result" would be one of "OK" or "FAIL".
  For a monitor process, it would be some serialization of the monitor
  data (or maybe a failure token).

  So an event listener conversation which transitions from
  ACKNOWLEDGED to READY to BUSY back to ACKNOWLEDGED and to READY
  again might go something like this:

  -> READY\n
  <- SUPERVISOR3.0 PROCESS_COMMUNICATION_STDOUT 30 22\n
  <- process_name: foo\ngroup_name: bar\nThis is the data that was sent between the tags
  -> RESULT 2\nOK
  -> READY\n

  An equivalent monitor process conversation might look like:

  -> READY\n
  <- SUPERVISOR3.0 MONITOR_QUERY 30 20\n
  <- pids: 2601 2602 2603
  -> RESULT 10672\n<... big mess o' XML maybe ...>
  -> READY\n

  Once this works, extend the eventlistener configuration to accept a
  "handler=" parameter, e.g. "handler=supervisor.process.stdhandler"
  (the default) or "handler=mypackage.myhandler".  Handlers will
  accept two arguments: one named "event" which represents the event,
  and the other named "response", which represents the listener's
  response to the event.  A handler either executes successfully or
  raises an exception.  If it raises an exception, the event will be
  rebuffered.  If it does not, the event is considered successfully
  processed.  A handler's return value is ignored.  Writing a handler
  is a "in case of emergency break glass" sort of thing.

  The 'standard' eventlistener handler will essentially do nothing if
  it receives an "OK" and will raise an exception if it receives a
  "FAIL" (emulating the current behavior).  A custom monitor process
  handler, on the other hand, might restart a process if it detected
  one was using too much memory, or would raise an exception if the
  serialization returned indicated failure.

- General speed improvement wrangling:

  - Play around with creating a select trigger file descriptor for
    each event pool.  Maybe when an event is accepted by the pool,
    write to the file descriptor.  This will cause select to time out
    and fall through.  In an asyncore dispatcher represented by the
    file descriptor, attempt to dispatch the event.

- Support stopping and starting groups in web interface.

- Support operations against both stderr and stdout logs within web
  interface.

- Revisit test_startProcessGroup and test_startAllProcesses (see XXX
  comment about ordering).

- Address outstanding collector issues.

- http://swapoff.org/wiki/blog/2007-09-09--distutils-support-for-a-workingenv-sandbox

- We *might* be able to delay shutdown until all buffered events have
  been processed (or a timeout has been reached).

- Web interface:

   - Support POST requests.

   - Unit tests for meld classes and ui server.

   - Meta-refresh on tail page.

- Expat error on Jens' system running slapd as root after reload.

- Unit tests for log rotation.

- Command-line arg tests.

- Provide a way to get the supervisord pid from supervisorctl/web interface.