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
- 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
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.
These are numeric and generated on demand. They are purged nightly to avoid garbage accumulation. These URL's should not be bookmarked.
These are alphabetic and managed by the system administrator. They represent the 'official' entrypoints and thus may be bookmarked.
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.
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>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 !
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
- 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.
- Use the name of your local proxy server or eliminate the first line if you don't care.
- Write about your own proxy policy (if you have one, see
- Insert your robot policy.
- Adjust the header to your local needs.
- Adjust the page footer to your local needs.
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.