Scheme Boston: Notes from October, 2002 meeting

Notes by Ed Kademan <kademan@phz.com>

The second meeting of Scheme Boston took place at Northeastern University Tuesday night October 22, 2002. There were approximately 14 people in attendance to hear Paul Graunke and Paul Steckler talk about using Scheme in web programming. Paul G. described the main ideas behind the Scheme web server and Paul S. elaborated on that by describing his implementation of a help facility for PLT Scheme based on that server.

Paul Graunke started off by noting that the web environment presents some unique challenges for programmers. For the most part these revolve around the fact that users need to be able to call up information and then navigate through it in a straightforward way. Clicking on a series of hyperlinks creates a string of pages that one can revisit either by moving backward in a sequential way or---if bookmarked---by jumping directly. This is not much of a problem if those pages display static content. But more and more web applications require that the server not simply display but actually create or elicit the content that it provides. For applications that access databases or otherwise run server-side jobs the "leafing through pages" metaphor is grossly misleading.

As a result servers have had to incorporate awkward solutions that may not offer the best performance. The CGI protocol for example allows a server to run external programs. But if those programs do any more than take simple requests and generate simple unchanging responses they have to somehow keep track of their states so that if the user returns to their "pages" the programs can pick up where they left off. This requires encoding their states and writing them out as cookies on the client's disk.

Scheme in general and PLT Scheme in particular have facilities that provide natural solutions to these problems. Foremost among them is the support for continuations, which allows a procedure to encapsulate a computation up to a certain point and save it so that it can be resumed later. Web programs in the Scheme server can create continuations, associate them with URLs, and store them away in a table. When the user visits these URLs---to elaborate a query say, or fill out a form---the browser actually invokes the associated continuations.

The server has to manage these continuations carefully since it may not always make sense for users to revisit such dynamic URLs. Once they have committed a form or placed an order they shouldn't be able to do it again---so that they get billed twice when buying products from an online retailer for example. In any event there has to be some way of eliminating useless URL entries so that the garbage collector can reclaim their storage. For this reason the Scheme server has procedures for cleaning up after itself. This is made easier by some of the other features of PLT Scheme such as its module system and its support for threads and custodians. (A custodian is an object that allows an execution context to register the resources that it is using so that when it comes time for it to die the server can release them. This feature along with the ability to create individual threads of execution and to define objects in modules---and not in global namespaces---makes it easy for the individual web programs to run safely and not interfere with one another.)

Paul G. concluded with some performance statistics. As measured in number of connections serviced per unit time the PLT Scheme Server had about 80% of the power of Apache on static web pages but was much faster on CGI. It was roughly comparable to Apache with Fast CGI---a system where that server communicates with a persistent external process instead of restarting one for each individual request. He also mentioned that in developing the server it was possible to use the general DrScheme tools for debugging and tracing.

Then Paul Steckler took over and described the help facilities for PLT Scheme. Since 1999 PLT Scheme has had a Help Desk which at first consisted of a custom-built browser that worked on the variety of more-or-less ad-hoc document formats that had grown up around the system. In order to get out of the browser-writing business and simplify the updating and creation of documentation he decided to rewrite Help Desk so that it made use of the Scheme web server. This way users could run general browsers with which they were familiar and the documentation could be written in true html. (This is important since users can create and incorporate their own local help documents.)

The reimplementation encountered some relatively minor problems. There are some incompatibilities in the way particular browsers handle some features---frames for example---and Scheme on some versions of Windows had trouble connecting. It also became necessary to refurbish and retain the old help browser since the new one depended on TCP/IP networking and not all users had networking enabled on their machines. But overall the new system is an improvement. It no longer depends on the customized thtml format which provided for Scheme code escapes and was a security hole, and can now use the cleaner S-expression version of html that the Scheme server recognizes. Help Desk also exploits the dynamic features mentioned earlier. For example it has a slick form-based interface for eliciting bug reports.

The next meeting will be on Nov 19th at the same place, 206 Egan. Neel Krishnaswami volunteered to talk on hygienic macros.