Tour of PWS

Here is a brief tour of the key classes in the Pluggable Web Server.


The core of the PluggableWebServer is the class PWS. For the most part, it works very much like Georg's server. There are class methods that wait for a socket connection, then an instance is spawned to handle the request.

The uninterpreted URL is available via the method url. The URL is parsed into pieces on a variety of delimiters: '/.?:='. The pieces are available in an array message. The input forms are available in the dictionary fields. The username and password are concatenated (encoded) in the userID.

message at: 1 is used as a key into the ActionTable. If present, the corresponding action is asked to process: the request. If not, the Default action is asked to process the request. (See Server Actions for more on provided server actions.) This was the simplest starting point, but I'm not too happy with it. I may change it into more of a rule-based firing later.

The PWS also provides class methods that can return standard HTTP codes for success, notFound, redirect, etc. Objects can also addToBackupJob: blocks which will be executed hourly when the image snapshot occurs.


The Authorizer is a generalized form of the UserMap authorization mechanism in Georg's WebServer. I typically run several applications with several user groups on my servers with more fine-grained control of authorization (e.g., a teacher from class A can access any of class A's materials plus class A's grades, but not class B's grades). Authorizer instances could be created in association with ServerActions or any other classes.

Each instance of Authorizer keeps track of the users (username + password encoded mapping to a username) and realm that is being authorized. An authorizer can be asked, using user:, to return the user name (or symbol or whatever) that has been associated with a username and password via mapName:password:to:.


The HTMLformatter is my attempt to put all the knowledge about HTML in one place. All of the services for the HTMLformatter are class methods -- I wanted the HTMLformatter to be globally available for use in embedded scripts, and I didn't see a need for multiple of them.

There are four method protocols in HTMLformatter. The formatting protocol contains a whole bunch of nice methods that generate HTML tags, many of which are taken from Tim Jones' HTML Composition classes. The pages and forms methods provide start and end sets of tags for pages and forms. The note support protocol contains methods for formatting a list of notes -- useful for the kind of collaboration environents I do. Some of them are used in Comment and Chat examples. The translating protocol contains two important methods:


The Session class is based on the WebtalkSession class in Tim Jones' WebTalk. The idea is to create a session instance which resides on the server, containing data that you want to exist between pages but that you don't want to encode into the page. Instead, you simply encode (in a hidden field) a Session ID. Sessions grow old and time out if not accessed within a certain period.

After creating a new session (which can be manipulated as a dictionary using at: and at:put:), the session can be saved to the Sessions list by telling the Session class to store: it. A random integer is returned as the session key. A session can be retrieved by handing the Session the ID via the recall: method. You retire: a session that is no longer needed.

Each recall: or use (at:/at:put:) updates (touch) the session's last ue time. A session that is older than the viableTime will generate an error when accessed. Every hour, the PWS cleans out old sessions as a BackupJob.

"More About Squeak..."
Home Page for How To Squeak

Last modified at 1/30/98; 10:02:53 AM
Other Links of Interest
College of Computing | EduTech Institute | GVU Center
Mark Guzdial | CS2390, Modeling and Design | STABLE