How CGI Works
Server-side applications involve more than one simultaneous process. The Web server software (which is running at all times) calls your dBASE Plus application to perform all the tasks you designed, and then grabs back control when your program completes execution.
While your dBASE Plus server-side application is loaded in memory, it's done so as a child process of the Web Server. Since there's going to be more than one application running at the same time, and these applications have to talk back and forth pretty intimately, a set of rules and regulations for interprocess communication is required. Those rules and their implementation on the Web server go under the acronym of CGI, Common Gateway Interface.
The CGI Protocol defines;
The capability of your server to pass and regain control from a child application.
The circumstances under which your server sends data to the child application and retrieves its output.
All major Web servers support CGI in one form or another. Win-CGI was specifically designed for Windows Web apps, but is supported only in O'Reilly's WebSite on Win 95/98 (and it's terribly slow!).
Most servers support CGI-bin (also known as standard CGI), which uses a direct connection, at the operating system level, between the Web server and your server-side applet.
Tip: Standards exist so that everything will work together smoothly, but open standards don't give much of a competitive edge. As a result, both Netscape and Microsoft have come up with proprietary alternatives, ISAPI and NSAPI, respectively. The only advantage of these single-vendor protocols is that they don't require a child process - they use a DLL to put your app in the same process as the Web server itself. Sounds great, right? No. Our benchmarks show no real-world performance advantage to NSAPI or ISAPI over dBASE Plus running in straight CGI (following the open standards, as it were). Furthermore, proprietary standards are proprietary, not standard, which leaves you at the mercy of the vendor and its own strategic purposes.
How the Web Server Talks to a Server-Side Application
Because you want your dBASE Plus applets to be able to communicate with all possible servers, you'll use CGI-Bin ( the "other" - actually the original - CGI protocol for all your server-side applications). CGI Bin communicates in one or more of the following methods:
Command Line method In the Command Line method, the Web server sends the data as a string parameter to the server-side application. The following Web address is an example of Command Line interprocess communication:
http://www.ksoftinc.com/cgi-bin/myprog.exe?firstname=Alan%&lastname=Katz
Environment Method Since your dBASE Plus application is a child process of the Web Server software, the Web server determines what environment will be available to your application. We're talking a real DOS-style environment block. Name/Value pairs sent back from an HTML form are stored in an environment variable called QUERY_STRING. However, it does so only if the HTML form uses a "GET" method to send the page back to the server. We don't recommend using the GET method, so forget the "environment" option for the moment.
StdIn/StdOut Method The third method of communication between Web server and server-side applet is StdIn/StdOut. Until now, StdIn and StdOut have been generally unknown quantities to dBASE Plus developers, but UNIX developers know them well and DOS developers have used them for years. StdIn and StdOut are streams - a pipeline of moving data that can be identified and grabbed with a file handle. It's not a real file, written to disk, but is treated as such by DOS. You've used them many, many times, though perhaps unwittingly. When you "TYPE" a file in DOS, you're streaming its contents to the screen using StdOut. Every time you type on a keyboard, a character is sent to the computer through StdIn.
dBASE Plus Web applications can, for the first time, access StdIn and StdOut using the built-in File class. Here's some typical syntax for opening StdIn and StdOut (you'll see similar code in the dBASE Plus Web Classes):
fIn = new file()
fIn.open('StdIn')
fOut = new file()
fOut.open('StdOut')
Note: You neither create( ) nor close( )a file object when using StdIn or StdOut. They are a pipe over which data will be streamed, meaning the Web server already opened these pipes from its side. You're the child process - you're just connecting to an existing pipe.
Another Note: The surfacing of StdIn and StdOut was quite a coup for dBASE Inc. and its talented engineering team. According to Microsoft's developer-level tech support, it couldn't be done. Well, it certainly can be done in dBASE Plus! The difficulty was that the "conversation" , that happens over the StdIn and StdOut pipes, happens at the console level (remember SET CONSOLE TO? ), meaning they are essentially DOS routines. Windows doesn't like to let Windows apps talk to the DOS layer. Something about a loss of control. No matter, we got it working and it dramatically improved the already-fast performance of dBASE Plus on the Web.
We recommend you use the read( ) method of the File class to get your data from the Web server. The Web server will conveniently drop some information in your applet's environment block that tells it how the data was submitted and how much there is, as shown in the following code:
cPostType = getEnv('REQUEST_METHOD') ==> "GET" or "POST"
nLen = getEnv(' CONTENT_LENGTH') ==> length of data stream
if cPostType = 'POST'
cInputStream = fIn.read(nLen)
endif
When sending data back to the Web Server, we recommend you use the puts( ) method of the File class, rather then the write( ) method. The puts( ) method was designed specifically to send strings rather than streams. It adds carriage returns and line-feeds to the end of every string. Since the data you'll be sending back to the Web Server is in the form of HTML (which is very line-oriented), the puts( ) method will make your life much easier. You won't have to deal with terminating characters. dBASE Plus will take care of that for you.
fOut.puts('<HTML>)
fOut.puts('<HEAD>')
fOut.puts('<TITLE>Welcome to dBASE Plus/Web</TITLE>')
fOut.puts('</HEAD>')
etc.
(See WebClass.cc for more detailed and documented code).
The best thing about dBASE Plus is that you don't have to know all this stuff. It certainly can't hurt to understand what you're doing (especially when something goes wrong), but the dBASE Plus Web Class's connect( ) method does all this stuff for you transparently. Aren't classes great?