4. The Director

4.1 Overview of Benefits and Features

NEW FEEDBACK WINDOW

Replaces cattail (tail -f) and attaches to CFHTLOGU for log messages. Color handled by ncurses. Director on non-color terminals uses bold and reverse video to highlight things.

VIEW IN MULTIPLE PLACES AT ONCE

Keeps track of recent messages in shared memory so other Director processes can listen in and provide another view, even on a different terminal-type, or with a different subset of messages! (i.e. one window shows debug messages, the other has them suppressed.)

NON-SCROLLING TEXT REGIONS

The terminal's window manager title bar, a status bar above the command prompt, and additional "debugging" info bars below the command prompt are easily configurable by echoing simple text messages to the Director window (through cfhtlog, or directly from an agent's standard output).

CLOCK, DISK FREE, DETECTOR TEMPERATURE

All of these displays are now available in the Director feedback window rather than as separate windows. Reduces clutter on screen and simplifies xtemp/xdisk applications.

CAN BE ``PARENT'' TO MOST COMMAND DRIVEN PROGRAMS

The Director itself plays the roll of OCS for the agent that runs inside of it. The agent can be (1) a local process on the same machine, (2) a process on a remote machine, (3) a process talking through an RS232 port or terminal server port. (UPS, Prolog, ... doesn't have to be Unix.)

TEACHES SYNTAX FOR SCRIPTING

The flow of information in Director/Agent provides a tool for training users on the command syntax as they use the system, even if they are only using the GUI! This is because every GUI action translates to some cli command which they will see echoed in the feedback window.

SAFE COMMAND INTERFACE FOR THE USER

At the prompt window, users will find a well behaved area into which to type their commands, easy line editing key bindings and command history, a backspace key that works, etc.

INTERRUPTS CAN BE DELIVERED USING A COMMAND

The prompt area of the Director window is always "live", even if the system is busy. This allows things like sending a signal with a command (e.g., user types "abort(enter)" and SIGINT gets sent.) A GUI could have an "Abort" button without any special logic behind it to send the command. (Echoed to Director as if it were any other command.)

TWO OPTIONS FOR SCRIPTING

The easiest way to write a script for Director is to type the commands into a kind of ``batch file'' and then ``source'' it at the Director prompt. The commands will be processed one-by-one until one fails or the end of file is reached.

The second way to write a script assumes the user is familiar with at least some kind of unix shell or script language. Using the utility "clicmd", commands can be passed to the Director. The exit code of clicmd reports on the success or failure of the command. This method provides the same flexibility that users have always had by being able to call Pegasus handlers, but rarely used (perhaps we are guilty of not providing adequate examples?) In fact, users can write a script that combines calls to handlers and clicmd. Use the second option if you need things like loops and conditionals.

CCD HOST LOGS MOVED TO SESSION HOST

Easy way of getting ccd logs to session host's roll file. All important messages now in one location.

4.2 Program Flow Chart

Figure 6 is a flow chart outline the logic implemented in the C++ code of the Director program.

Figure 6: Director Flow