The easiest way to become familiar with sniffle is to use it, so we'll examine what happens when we write and submit the world's most famous program to the interpreter from a Web client. The first thing to do is load the sniffle program form into your Web browser. The URL is http://piper.princeton.edu/webrti.htm. This form contains a ``textarea'' containing a sample program. If we delete the sample program completely, enter the string ``hello world'' in the textarea, and then click on the ``Submit'' button, we send that string to the command interpreter.
If all goes well at the server end, it won't be long before we receive a reply. We should get a document containing a link to the session log that records the results of the command we submitted. We're interested in the session log, so we follow this link. It should look something like this:
BEGIN PROGRAM 02:04:44 9/12/95 RTI Initialization: COM Initialization: READY; 0/1 : HELLO WORLD : Unrecognized command passed to routine Exec END PROGRAM 2:4:45 9/12/95
The first and last lines of this output record the times when the interpreter program (a Visual Basic program called WEBRTI.EXE) started and terminated. The second and third lines record the results of I/O board and serial port initialization, respectively. In the next line the interpreter ``echoes'' our command, indicating that the command was received. In general, for every command interpreted by WEBRTI.EXE one line is added to the session log. This line consists of three parts delimited by colons.
The first part is a number which records the ``depth'' of the command followed by a slash followed by the command number. In our example, the depth of our command is zero, and we submitted one command, so in our session log we have ``0/1.'' The second part of the line is the command itself, and the third part contains either values returned (in the case of input commands, described below) or error messages. The sniffle command interpreter is robust and functional, but it isn't very sociable. It didn't recognize our greeting and says so.
We don't ever want two clients operating the I/O board or digital oscilloscope simultaneously, so the server has a primitive notion of ``ownership'' implemented by a crude but effective file-based locking system. Whenever WEBRTI.EXE is executed by the WinHTTPD server, one of the first things it does is check to see if a lock file exists. If so, a message to the effect that the system is locked is returned to the client. The client then has the opportunity to ``break'' the lock by forcibly deleting the lock file. This should only be done if it is certain that the server is erroneously locked (e.g. as a result of a server or WEBRTI crash).
If WEBRTI.EXE does not find a lock file at startup time, it creates one and then deletes just before it terminates. In principle, therefore, it shouldn't be possible for two Web clients to confuse the server by issuing conflicting commands.
Data feedback to the client takes two forms. The first and simplest consists of analog and digital input values detected by the I/O board. These are returned to the client in the session log. So if we tell the interpreter to read the whole byte of digital input by sending it the ``din'' command, we get back something like this:
BEGIN PROGRAM 02:37:03 9/12/95 RTI Initialization: COM Initialization: READY; 0/1 : DIN : value = 0 at 2:37:04 9/12/95 END PROGRAM 2:37:04 9/12/95
This indicates that all eight bits of digital input were ``low'' at the time the command was executed.
The second form of data feedback consists of oscilloscope dumps. These are generated by the ``tek'' command (see below for details). After a program has run its course, if instead of following he link to the session log we follow the link to ``Tektronix Dumps'' we will obtain a list of links to individual waveforms generated. Each waveform is a text file with a .WFM extension. The WinHTTPD server is configured to label these files with MIME type ``text/waveform'' when returning them to the client. MS-Windows clients can be configured to spawn the Tektronix DOS utility VIEW.EXE upon receipt of files with this MIME type. Alternatively, the client can load the .WFM file to local disk (in Netscape this is done by holding down the shift button while clicking on the link). The waveform file can then be decoded, displayed or manipulated at the client. The format of .WFM files is explained in Tektronix documentation.