Spider 1.5 is a set of tools that makes accessing a database from a Web server easier for developers and HTML writers and faster for end users. It substantially reduces the overhead of connecting to databases by caching the connections in its own daemon, and it allows you to improve performance further by distributing your database connections across multiple machines. In addition, Spider makes dynamic HTML (HTML templates with values substituted from a database) simple. One thing Spider does not address, however, is HTTP's well-known weakness in maintaining state across requests. In addition to the database access tools, Spider includes a modified version of the Mosaic 2.6 browser that allows you to drag and drop HTML form fields into the Spider development tool.
I installed the evaluation copy that is available from Spider's Web site on an SGI computer running Informix 7.10 and Netscape's Communications Server. The evaluation copy is fully functional but has a license that expires after 30 days. The software is delivered as compressed tape archive (*.tar.gz). Once the files have been extracted from the archive, you run a shell script, "stinstall," which prompts for an installation directory and the cgi-bin and document root directories of your Web server. At the end of the script, you are presented with an ID number to send to Spider Technologies in order to get a key to run the software. I received mine the same day I sent my request. You must then place the key file (Spider.key) and configuration file (SpiderNet.conf) in your /etc directory. To configure the bundled Mosaic Web browser, you're on your own -- Spider doesn't provide any documentation. If you're behind a proxy server, don't forget to set your http_proxy environment variable (or Mosaic*http_proxy in your .Xdefaults file) to something like "http://host.domain.com:12345/".
To configure Spider's database connections, run "spiderdev" and then select Managers/Databases from the menu bar. If your database is set up correctly, it's just a matter of a few menu selections. One thing I would change, though, is the storage and display of the database user password -- it is displayed as you type it in, and it is stored unencrypted in the Spider configuration file.
The last step is to start up the Spider engine, which consists of four modules: a request broker, a service manager, a CGI master, and a daemon master. The daemon master maintains up to a user-specified number of persistent database connections so you can get the most out of your database licenses. Each Spider module may be run on more than one machine to improve performance.
You use the "ktstart" command to start up and the "ktstop" command to shut down the Spider engine. You'll also want to include your calls to ktstart and ktstop in your startup and shutdown scripts so you won't need to remember to run them when you reboot your machine.
Creating a Spider application involves menu selections and dragging and dropping in Spider's development tool, followed by some HTML editing. Spider maintains the files and directories for your applications in "actions" and "templates" subdirectories under the application home directory that you supply. An application consists of a set of HTML template files (created with any HTML editor) and action files (*.i files, created by the Spider development tool). The action files are ASCII text, which may make things like version control easier, but you should probably leave any modifications up to spiderdev. Spider applications are invoked from the Web server using the URL http://www.company.com/cgi-bin/spider/app_name/file.html. If you use Netscape's NSAPI, you'll need to add a few lines to your Web server configuration files (magnus.conf and obj.conf) and remove the "cgi-bin" from your URL, but the principle is the same.
To create an application, select File/New App from the menu bar and fill in the application name, home directory, and database to which you want to connect. Then select File/New Action to create your action files within that application. Spider then presents two windows: one for specifying the details of your database transaction, and the other for viewing the structure of your database.
The transaction window contains sections for defining the type of transaction (query, insert, update, delete, stored procedure), a where clause (if required), input, output, and errors. You can click and drag fields with the middle mouse button from the database viewer window into your transaction window. The transaction window is fine for simple SQL statements, but it's a bit inflexible for more complicated queries or aggregate functions. A nice feature (included in most other database development tools) would be the ability to edit SQL statements directly. One way to accomplish something similar in Spider is to create a stored procedure containing your SQL, and then call it as one of your actions in your Spider application.
After you have defined the actions of your application, you'll need to create some HTML templates to make use of the actions. To insert a database field into your HTML template (and create a database "anchor"), just surround the field name with double-asterisks: **field_name**. You can also include conditional HTML in your templates by using Spider sections in conjunction with database stored procedures. You first include lines such as:
-- SPIDER SECTION section_name BEGIN -- -- SPIDER SECTION section_name END --
in your HTML template, and you then write your stored procedure to take the section name as its first argument.
Spider's HTML-based online documentation provides several examples of how you can use anchors, sections, and stored procedures in HTML templates to create more complicated drill-down or master-detail reports in addition to simple database field substitution. (See Figure 3, page 38.)
Spider doesn't add any new form controls to HTML forms; it just makes connecting standard HTML forms to a database easier and faster. With Spider, a developer must either write code to maintain state (for example, between pages of a multipart form), or design applications so that they don't require state (by making each form act as a standalone application).
For straightforward Web server database applications, Spider definitely boosts developer productivity. Its ease of use makes it ideal for developers new to the Web or Unix. On the other hand, if you have complex database requirements -- accessing multiple databases, for example -- or if you need to support arbitrarily complex SQL, you'll be better off with lower-level database tools, knowing that you'll also lose Spider's other major benefit, performance.
Performance is difficult to generalize across different hardware, network, and database configurations, but Spider addresses those concerns in two ways. First, by openly describing the Spider architecture for maintaining persistent database connections, Spider clearly confronts the biggest bottleneck in accessing databases from a (connectionless) Web client. Second, Spider makes its software available from its Web site for a free 30-day evaluation, so you can test and judge for yourself whether Spider's performance and simplicity are worth the cost.