PWS is pluggable in three ways:

• Decoupled URL Parsing and CGI Execution: The core of PWS is Georg's WebServer -- that is, the networking components and the parsing of the HTTP header. However, the interpretation of the URL (e.g., in Georg's WebServer, the URL is interpreted as an object and message; in Tim's WebTalk, the URL is a class name; and in most servers, the URL is a file reference) is decoupled from PWS. Instead, a separate ServerAction is handed the PWS request, and the ServerAction can determine how to interpret the URL and what to do to return (e.g., pass on a file, execute a CGI script and return the result, etc.). A PWS contains a table of ServerActions, so a single server can interpret URLs in several different ways.

• Pluggable Server Actions: There are two ServerActions provided that are pluggable in the traditional sense: The instances hold the blocks to be executed for URL interpretation and as instance variables. PluggableServerAction takes a processBlock and a returnBlock for processing any forms input and then computing a return HTML page, respectively. A SinglePlugServerAction just takes a processBlock and requires the processing block to get the response back to the request.

• Embedded HTML: EmbeddedServerAction serves files, but wherever it encounters <? ?> tags, it evaluates the embedded string as Smalltalk and replaces the tag with the result. The actual interpretation and replacement occurs in the HTMLformatter class, which can be used as-is in Georg's or Tim's servers, too.

Overall, what this buys you is:

• Design your URLs to have whatever information you want encoded however you want
• Build your problem domain classes with minimal concern for CGI or HTML issues.
• The interface and navigation issues are separated into the HTML pages, not embedded within CGI scripts that generate them.
• Finally, some CGI applications can be completely embedded in a single HTML page.