next up previous
Next: 6.2 Interoperability Up: 6. Conclusions Previous: 6. Conclusions

6.1 Other Systems

I have written many server systems in SETL to date. Most of them have been small and even trivial, which is as often desirable in a server hierarchy (Box) as in any other system. Others have necessarily been larger.

For example, one Box which is of intermediate size is the PWM Toolkit. Its ``business end'' sends commands on a serial line to a program in a PC-cum-microcontroller which generates effective-voltage control signals on any subset of the pins of a parallel port by direct pulse-width modulation (PWM), i.e., by carefully timed, very rapid toggling. It has been used to drive the spherical pointing motor [26,25] through an H-bridge switch.

The PWM Toolkit supports several possible methods and modes of signal generation, some of which involve dependencies between pins. Besides controlling the various basic quantitative parameters of PWM, the toolkit can generate time-varying envelopes, including some cyclical patterns with their own parameters such as maximum, minimum, frequency, and phase.

The PWM Toolkit may be used by telnet clients (it has a command-line interface with a help command) or more conveniently by a GUI client, which uses the command-line interface to the server but presents to its user a master window and zero or more detail windows that depend on selections made through the master window. The windows themselves are all created and governed by a wish shell process that reads dynamically generated Tcl/Tk [184] command scripts.

The widgets created by these scripts are originally specified by templates consisting of nested tuples in a SETL program, where the horizontal or vertical layout of GUI elements at a given nesting level is controlled by whether the level is even or odd. The wish process is attached to the SETL program through a pump stream. The Tcl/Tk commands are issued by the SETL program on this stream to build, destroy, and update widgets based on inputs from the user and from the PWM Toolkit server. Each widget, whenever the user manipulates a control, sends information to the SETL program on the pump stream by writing a short message to what the widget sees as the standard output stream of the wish process--this is the main way the SETL program receives user input, although it also keeps a debugging stream open for users to enter arbitrary wish commands, which it merely passes along. Web clients using an interface known as LogEye [17] to view a foveated ``log-map'' image also implicitly communicate with the PWM Toolkit server when controlling the effective pan and tilt voltages supplied to the spherical pointing motor on which LogEye's miniature videocamera is mounted. All clients which have issued the notify command to the server receive notice of all parameter changes. The GUI clients automatically issue this command on startup, which has the interesting and useful effect of causing all the sliders and other controls associated with these clients to change state automatically (in real time, from the user's point of view) when other clients modify parameters through their controls. It is even possible for two users to get into a tug of war by dragging similar controls in opposite directions. This keeps the server rather busy changing parameter values, but causes no real harm except perhaps to a hardware device that has difficulty with rapidly changing effective voltage levels.

The LogEye system just mentioned and another Web-interfaced service I wrote called LabEye [16] are in some respects similar to the WEBeye of Chapter 4 [WEBeye: A Case Study], and antedate it. They cannot really be described as simpler than WEBeye. LogEye, for example, has the ability to manage, filter and cache a variety of live and stored image streams simultaneously, and features a calibration procedure for interpolating the PWM values that should be used for aiming a videocamera based purely on convolving image samples corresponding to various PWM settings. LabEye allows the user to control and view patterns on an oscilloscope and two bi-color LEDs using a browser interface to a server which indirectly commands a BASIC Stamp [167] that in turn controls a circuit of my own construction. These systems have acted as proving grounds for many of the SETL-based, process-intensive techniques outlined in this dissertation.

Richard Wallace has also used the Box approach in the SETL prototype of his ALICE [206] artificial-intelligence conversationalist. Its primary interface was through a Web browser which communicated with a server written in SETL. That server spawned a child process to read client input and send MIME-wrapped HTML code in reply, just as the httpd interface of WEBeye does. In the best modular tradition of Boxes, the original ALICE made use of filters and pump streams invoked from SETL, and of another server which did the main work of natural-language processing. Some user input strings were interpreted as commands to move a videocamera, so ALICE also played client to the camera-control server side of LogEye, and embedded a reference to the video server aspect of LogEye in the HTML sent to the client browser, in order to serve the user a picture (usually a live one), a textual response, and a prompt for more input.

The idea of embedding, in the HTML sent to a client presumed to be a browser, a reference back to the server which generated that HTML (or at least to a server which is in turn a client of that HTML generator) is used by WEBeye, LogEye, LabEye, and ALICE. In fact, this kind of self-reference, in an imagemap, was used in the original LabCam at NYU. It is similar in spirit to the use of a CGI script, but bypasses the need for a full-fledged Web server to be involved at every step of what is often a fairly long-term interaction. The general principle is appropriate whenever a Web page is designed to lead the user to a similar page one or more times.

My use of SETL for processing Web-based requests began with CGI scripts, and I feel it is still useful in that role. For example, the rudimentary comp.lang.ada interface service [14] I wrote when visiting Alfredo Ferro and his colleagues in Catania in 1994 was not only moderately useful in the rather speed-limited network environment that prevailed there at that time, but was also one of the earliest tests of ``sockets for SETL'' as I termed the first, TCP-only version of the current set of SETL library extensions for network programming.

The ``Famous Original'' SETL Server [13] that has been accessible through my home page [15] for several years is not actually a server at all in the TCP/IP sense, but simply a rather general CGI script which allows any user to run a SETL program by entering it directly into a text sub-window on a Web page or by giving a URL at which the program can be found. Similarly, run-time inputs to the SETL program can be supplied in either of these two ways. Since the SETL program runs on the Web server host or a delegate thereof, it is run in a restricted mode which prevents server-side abuses such as the clobbering of arbitrary files. The administrator of the SETL Server can allow guest programs some latitude in opening client sockets, however, by configuring a set of host:port combinations that foreign programs are allowed to connect to. This is mediated by the support for the secure restricted mode that is built into my SETL implementation.

next up previous
Next: 6.2 Interoperability Up: 6. Conclusions Previous: 6. Conclusions
David Bacon