Squeak Web Server


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

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

Principles of Operation


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 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.


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 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 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.


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

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.


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