Squeak Web Server

Introduction

This is a web server for Squeak, implemented entirely inside Squeak. Its purpose is to make Squeak a web-based OODBMS/object server/application server (pick your name). Some of its features are

user authentication
forms support
transaction logging for image roll forward in case of a crash
per user undo facility
nightly housekeeping operations

Note: Currently this is not a full fledged HTTP 1.0 server, namely

no support for simple requests (nobody sends them anyway)
any request that is not POST is treated as GET

Principles of Operation

URLs

The server handles URLs of the form 'objectId.message'. Additional parameters delimited by dots may be appended.
Since OOP's are not fixed in Squeak the web server maintains its own objectId's. There are two kinds of them

automatic
These are numeric and generated on demand. They are purged nightly to avoid garbage accumulation. These URL's should not be bookmarked.
manual
These are alphabetic and managed by the system administrator. They represent the 'official' entrypoints and thus may be bookmarked.

Message is always a single parameter keyword message (with the trailing colon omitted) with the parameter describing the request. The corresponding method must be in the Category "HTML Reply" to be accepted otherwise a "400 Bad Request" message is returned. The same reply is triggered by any execution error.

Authentication

The WWW-Authenticate: Basic mechanism is used. It is up to the individual HTML-generating method to use the authentification information to decide whether the request is legitimate or how to customize the response. Utility methods provide for the RFC 1421 encoding of username/password combinations and mapping them to application defined 'user' objects.

Forms

Forms information is extracted to a dictionary with the field names as keys and the field data as values. Multivalued fields (multiple selection lists, checkbox groups) return an array of values.

Transaction Log

The log contains information to rerun all requests in case of a crash. Since this includes username/password information the log has to be kept as secure as the image itself. To guarantee (approximately) accurate timestamps when rolling forward Time has been augmented with a 'Bias' class variable. All senders of Time>primSecondsClock must be modified to apply the bias (Time>dateAndTimeNow and Time>totalSeconds in the standard image). During the night the image is saved and a new log created.

Undo

Undo is implemented by creating undo objects holding receiver, message, and parameters. It is the responsibility of the request (form) processing methods to build these objects. For the most common cases standard updating methods are provided. Every user sees only her/his undos, which are purged during the night.

Implementation

Get the current realease from SqueakMap.

Note: some of the material below is outdated !

Execute WebRequest serveOnPort: 8080 loggingTo: 'test.log'. Then load the URL http://your.server:8080/Server.home in your favorite web browser.

Notes on version 1.x

The code has been tested by loading into a virgin 2.3 image on the Mac.
As an example a simple memo framework is included.
Username/passwort for managing the server is "SysAdmin"/"squeak".
Don't save the image while a server is running, except with the Server.control.snapshot URL.
Roll forward is only automatic after a snapshot.
Code tuning

String constants
Some string constants are stored in the pool dictionary TextConstants.
TextConstants at: #HttpAuthorize
You may want to use a different realm.
WebRequest>getReply
Use the name of your local proxy server or eliminate the first line if you don't care.
WebRequest>noProxy
Write about your own proxy policy (if you have one, see WebRequest>getReply).
WebRequest>robots
Insert your robot policy.
WebRequest>title
Adjust the header to your local needs.
WebRequest>getReply
Adjust the page footer to your local needs.

Headless operation

To run the server without a GUI you need the headless version of the 2.3 Unix VM. Prepare the image by first setting the timeout value in ProcessorScheduler class>idleProcess to 10000000, thus letting the server sleep for 10 seconds if nothing happens. Then start the server by executing (after adapting port and log name to your needs)

WebRequest serveOnPort: 8080 loggingTo: 'test.log'. Sensor mousePoint = (0@0) ifTrue: [ Smalltalk snapshot: false andQuit: true ]

The second line will shut down the VM when the server is stopped when running headless but will leave it up when in GUI mode. Then invoke a snapshot via a web browser, stop the server - again via the browser, shut down the VM and restart the image with the headless VM.
Note that the VM will shut down immediately. Why ? You have encountered the roll forward mechanism :-)
The previus steps had left behind a log file with a shutdown command as the last (and probably only) line. Obediently the server has executed it. Simply start again since the roll forward has removed the old log. Of course you can manually remove the log before starting the headless VM.

When you open an image in GUI mode that has been saved in headless mode you will find that the window has shrunk to a small size. Just enlarge it as needed.

Multithreading

An area to tread with caution as one can easily corrupt data with improper synchronization !
Furthermore the roll forward scheme requires strict serialization of updates to work properly.

Currently only rudimentary multithreading support - geared to simple report generation - is implemented (see WebRequest class>threadTest:). There is no provision for locking so a background process must not change any shared data (even by generating hyperlinks) and must take into account that other processes might change shared data it reads.

Georg Gollmann