Client/Server and Program/Library Interfaces

The DODS client library and data server programs communicate information using URLs and MIME documents. Figures  and  show these two communication paths.

All information sent from the filter programs to the client library is enclosed in a MIME document. Two of the three programs return information about the variables contained in the data set as text/plain MIME documents. These documents can then be parsed by software in the client library. In addition, these text documents can be read by any software that can process ASCII text. Thus, the responses made by the server are specifically suited to use by the DODS client libraries, they can also be used by many more general programs. For example, it is possible the use a general purpose World Wide Web browser to `read' these documents.

The third filter program returns binary data encoded using Sun Microsystems External Data representation (XDR) scheme prefixed with text which descibes the data type of the binary information³. The data is enclosed in a binary MIME document whose subtype is experimental. This document can be read by software that is part of the client library using additional information about the data set that is stored as state information by the client library. Because correct interpretation of this document requires knowledge of the format of the binary information, it is not possible for general purpose WWW browsers to interpret this file (although most browsers can read and save to disk any arbitrary data).

In order to provide link-time compatibility with the original API libraries, the DODS client libraries must present exactly the same external interface as the original libraries. However, these new libraries perform very different operations on the data (although, for a API used to access a self-describing data format the operations are analogous). One difference between the two is that most data access APIs use file names to refer to data sets. In the simplest case these file names are given on the command line by the user and passed, without modification, to the API. The API uses the file name to open a file and returns an identifier of some type to the user program. Subsequent access to the data are made through this identifier.

In this simple scenario, it is possible to substitute a URL in place of a file name (in part because both are stored in string-type variables). This same user program can be invoked, on the command line, using a URL in place of the file name. The program will, in almost all cases, pass the URL to the API to open the data set. However, since the user program has been re-linked with the DODS re-implementation of the API, the functions in the API will correctly interpret the URL as a remote reference (see Section ). Clearly, one requirement that a user program must meet in order to be re-linked with DODS is that it must not itself try to open or otherwise manipulate the `file name' which will be passed to the API⁴.

As shown in Figure , the client library does manipulate the URL used to access the data set. A DODS data server is actually comprised of three programs which each respond to a different type of data as described by the Data Access Protocol. These programs are accessed as WWW documents via the HTTPD using the CGI mechanism. By convention the data set name consists of the HTTP access string (http://) followed by the machine name and a string which the data providers choose depending on the name and location of the dispatch CGI and the data. In order to read the DAS, DDS or data, this URL is modified, again by convention, by adding a suffix. The three suffixes currently (as of 23 August 1996) recognized are .das for the dataset attribute structure, .dds for the dataset descriptor structure, and .dods for binary data.

Figure: MIME documents are used by the server programs to return information to the client processes.

Figure: URLs are used in place of filenames to reference remote data sets accessible via a DODS data server.