The Application Interface for the WFO-Advanced Forecaster Workstation, D2D

To complement the D2D design, FSL developers created an efficient programmatic interface to simplify the integration of local applications into the system. In describing the functions of the D2D application interface, this paper covers how new and existing programs can become D2D applications, what requests they can send to the interface, and what notifications they receive from the interface. It also surveys the kinds of applications currently deployed along with the D2D software, and concludes with a comparison of the application interface with the D2D extension framework, an alternative way for forecasters and developers to provide customized functions to D2D.

To protect forecasters as they perform operational meteorology with D2D, the interface runs applications as processes separate from the core D2D processes; thus, if one of the applications crashes, it does not affect D2D. However, an application could still run amok and consume disk, CPU, or network resources that must be shared with the D2D software. To date, we have built no safeguards against this possibility.

In addition to being started by the D2D system, applications can also interact with D2D. The application interface provides a facility for programs to send requests to D2D and it also provides a mechanism for notifications to be sent back to running applications. These features enable an application to perform sophisticated processing, such as receiving a notification about what display scale the forecaster is currently using, generating a contour plot of isotherms on that scale, and then loading the plot into D2D's main display area.

Applications communicate with D2D using their standard input and output channels provided by the Unix operating system. Normally, the standard input for a program is the keyboard, and the standard output is the screen. The application interface sets up these channels so that the standard output actually sends information to the interface, and the standard input receives information from the interface. Because reading from the standard input and writing to the standard output is trivial, the interface makes it easy to develop nearly any kind of application---or to adapt existing programs to the interface.

Forecasters using the D2D software launch applications by selecting them from the D2D menus. Site administrators can add and remove applications from the menus by editing configuration files---without needing to recompile D2D software.

Writing the text @@-Load followed by a space-separated list of depict keys to the application's standard output will load each of the depictables represented by those depict keys. Certain depict keys are treated specially. If an application loads one of these special depict keys, then the application itself provides the depictable data in an external file in the netCDF format (Rew et al., 1996). The D2D software will read and render the data in the file on the display.

Like the shells, the D2D application interface also executes programs, which we call applications. Instead of typing the names of applications to run, users select them from the D2D menus. The applications always run asynchronously (to enable the core D2D software to continue running) and their standard input and output are always connected to the application interface, using Unix pipes. A pipe is a communications facility provided by Unix that enables one-way flow of data between two processes (Stevens, 1990).

D2D software constantly monitors all of the pipes connected to each of the running applications. Whenever an application writes text to its standard output, the D2D application interface reads that text and attempts to recognize any of the standard requests using a parser built with Lex (Aho et al., 1988). Since Lex automates parser construction, adding new requests to the application interface is simple. The application interface also queues notification text pending for an application and sends the text along the pipe connected to the application's standard input. The application then reads its standard input to receive the notification.

Only one copy of the Volume Browser may run per D2D display. If the forecaster selects the Volume Browser application from the D2D menus, the single Volume Browser that is already running is sent the visibility notification. Upon receiving this notification, the Volume Browser de-iconifies itself (if it was iconified) and raises its window.

One of our goals was to treat ISP as off-the-shelf software and modify its source code as little as possible. We partially achieved this by developing a wrapper---a small program that acts as an adaptor between the D2D application interface and ISP. The wrapper is a Tcl/Tk script that first sends the @@-Export command to export any skew-T data, and then waits for the exported notification. When it receives the notification, it displays a dialog box to ask the user to select one of the exported files (if there was more than one). Finally, it executes ISP with the selected file as an argument. ISP brings up its own windows separate from D2D to display the skew-T diagram, hodograph, and various parameters. Worthy of emulation, this wrapper technique enabled us to make a stand-alone program act as a D2D application. Other stand-alone or off-the-shelf programs can become D2D applications using the same technique.

Although the goal of both the application interface and the extension framework is to provide forecasters with locally-customized functionality, the two methods achieve the goal in different ways. As can be seen from the Table, the extension framework forces extensions to be tightly coupled to D2D: they must be written in a certain language and may run only with D2D. They can, however, be interactive on the D2D main display---that is, extensions can take action when forecasters edit objects on D2D's main display area.

TABLE: Application Interface and Extension Framework Feature Comparison

Feature	Application Interface	Extension Framework
Language	Any	C++ only
Stand-alone operation	Yes	No
How used	Text commands passed on standard input/output	Inheritance from base class, overriding virtual methods
Graphics	Static; load a netCDF file into D2D	Dynamic; create and change points, lines, polygons, etc.
Interactive graphics on D2D	No	Yes
Images	Yes	No
User interface	Any	Only through extension library

Applications, on the other hand, may create only static graphics for the D2D display, but unlike extensions, they may also create images. Forecasters cannot interact with the data directly on the D2D display area. However, applications can bring up any number of their own separate, floating windows, containing any kind of user interface elements, thereby enabling complex interaction. Also, applications can run "stand-alone," which simplifies application development simpler because a complete and running D2D installation is not required.

Some improvements can be made in the interface. For example, the arguments to several of the commands and notifications are integers whose meanings have to be looked up in tables (provided with D2D). We plan to replace the integer arguments with keywords that clearly show their meanings.

Other interesting work involves the possibility of expanding the set of commands to include features for programmability---that is, make D2D support scripts. The Tcl language (Ousterhout, 1994) is perfectly suited to this task: it is an embeddable scripting language that offers flow control, conditional expressions, loops, and procedures. By implementing the D2D application interface with Tcl, we foresee a myriad of possibilities: macro recording and playback, automated weather briefings, direct conversion and presentation of local datasets, automatic response to severe weather, and much more.