B. F. Rasmussen
Space Telescope-European Coordinating Facility, Karl-Schwarzschild-Strasse 2, D-85748 Garching bei München, Germany
To run WDB, all that is needed is the WDB script (written in sybperl) and a set of high-level form definition files, each describing a different view on the database. WDB automatically creates HTML forms, on-the-fly, to allow users to query the database, and given these query constraints, it will query the database and present the result to the user. WDB even comes with a utility to automatically extract information about a table from the database and create a working template form definition file.
A number of conversions are possible on the data coming from the database before they are shown to users: formatting of coordinates into hours, minutes, and seconds; formatting dates; etc. The most noticeable feature is the possibility to convert data from the database into hypertext links---and as it is possible through WDB to access any database element directly via a Web URL---the entire database can then be turned into a huge hypertext system. These hypertext links can be links to other elements in the database, thereby providing a simple way of jumping between related information. There could also be links to other documents on the Web, providing easily integration between data in the database and related documents on the Web. One could also have links to other databases with a WDB or similar interface---providing a simple mechanism for cross-database links.
WDB is implemented as a CGI script which can generate forms and send them to the user, retrieve the contents of the form, process it and return the results to the user. The forms and description of how the individual fields in the form links to fields in the database are defined using Form Definition Files ( fdf's) located on the server.
Figure: A WDB Connection. Original PostScript figure (3 kB)
Due to the nature of a WWW connection, the WDB system has to be designed differently from a normal database application (see Figure 1). As there are no long-lived connections, the server has no notion of what has been going on earlier in a session. The WDB process is exited immediately after the results are send back to the user. This means that all information needed to perform a given action has to be sent from the client each time. Of course, the client will have this information from the last result it received from the server.
The way this information is sent back and forth between the WWW client and the server is by the URL. It is a standard for specifying a piece of information on the Internet, and is composed of a protocol name (ftp, http, gopher), the name of the server, and a path on that server pointing to the piece of information needed. This can be a file or, on an http server, a CGI script such as WDB. The trick is that if there is any extra information in the URL after the path, then it is passed to the script as what is called PATHINFO.
(ex. http://arch-http.hq.eso.org/cgi-bin/wdb/ PATHINFO)
The actual flow of control is better illustrated in Figure 2. What happens is the following :
Figure: Flow of Control. Original PostScript figure (5 kB)
WDB has proven very successful---mainly because of its simplicity and the ease with which it can be extended. One of the goals of WDB was to provide an easy, yet flexible, way to make database information available. In the simple case, no coding should be necessary. However, if special behavior is needed, it should be possible to add it without changing the core system. Also, if some special behavior has been defined for one field in a form, it should be easy to reuse this in other forms.
This has been achieved by allowing extensions to be added in the individual Form Definition Files using the powerful Perl language. This makes local customization a lot easier than with most existing WWW/Database gateways.
WDB already has a large user base. At the time of writing, more than 30 sites world-wide have installed it. An e-mail mailing list is maintained for announcements of new releases. To be added to this list, send e-mail to the author ( email@example.com).
McCool, Rob 1993, The Common Gateway Interface, National Center for Supercomputing Applications (Champaign, University of Illinois)
McCool, Rob 1994, NCSA httpd Overview, National Center for Supercomputing Applications (Champaign, University of Illinois)
Brenner, Steven E. 1994, CGI Form Handling in Perl (Cambridge, University of Cambridge)