Since OPeNDAP is built inside a data access API, and since the application program that has become the OPeNDAP client was presumably not built with network I/O in mind, an OPeNDAP client will typically not do any processing at all while it awaits a return message from a data request. Any communication that must happen between the OPeNDAP software and the user must occur without the involvement of the application program that has invoked the OPeNDAP software. To avoid this limitation, OPeNDAP starts up a GUI manager sub-process. This sub-process can receive data from the OPeNDAP core software, and can operate the user's graphical user interface.
The operation of the GUI manager is illustrated in figure 5.3.1. As seen in the figure, the client application can usually control the user's screen, but during a data request, this communication is suspended. Until the request returns control to the client application, messages returned from the OPeNDAP server can be displayed to the user by passing them to the GUI manager sub-process, who can display them in a window to the user.
wish program is the default) to interpret messages from the
server. These messages usually contain Tcl programs to display
information to the user. However, the wish interpreter can also
be sent programs to query the user for more information, or draw
little rabbits on the screen or any other graphic function the server
needs to have displayed to the user. See Tcl and the Tk
Toolkit [3] for more information about Tcl.
By default, the GUI manager initializes by running the Tcl programs in
the files dods_gui.tcl, error.tcl and progress.tcl.
(These are stored in $DODS_ROOT/etc.) Server commands to the
GUI manager can use the functions defined in these files. Note also
that the user may be using a "safe" Tcl interpreter, with a
restricted subset of the usual array of Tcl commands available to it.
The user can control these features of the operation of the GUI by
changing several environment variables. These are described in
Section 2.3.2.
A server will use the features of the GUI manager to display error messages to the user. A server may also use the GUI to query a user to correct whatever condition caused the error. For example, if a user has misspelled some part of a constraint expression in a URL submitted to a server, the server can send the constraint expression back to the user in an edit window, with instructions to fix it. The user can edit the expression, and send it back, allowing the server to proceed without submitting a new request. Consult the client and server toolkit manual for more information about the Error object on this subject.