>Currently, PWS is a class-side application. Close inspection reveals
>that PWS class is a web server, whereas a PWS instance is actually an
>HTTP request. Thus, yes, only one PWS per image is possible.
>
>I'm currently working on restructuring the PWS to support, among other
>things, multiple servers per image.
>
>One trick to run multiple PWS's is to subclass it. But you may need to
>check out direct references to PWS and replace them with self or self
>class (for PWS class and instance respectively) or, for other objects,
>create a way to reference the correct server.

According to Ralph Johnson, this is a shanda (translation: really 
groty and losing thing).  Using classes as a vehicle to enforce 
singleton's is one thing, but the difficulty with that approach is 
precisely that it invites problems when reusers desire to produce 
multiples instances in the distant future.

His specific example of the recipe for disaster in the "Classic 
Smalltalk Bugs" memo is precisely what is suggested here: using 
subclassing of a class-as-singleton class to achieve multiple 
"instances" thereby.

Perhaps its time to recognize the truth of the matter, and call a 
class generating server instances Server, and the class generating 
request instances Requests.  Enforce singletons in a more 
conventional manner, while still paving the way for later 
applications that might find plural servers to be a "real good thing 
tm."

While there is an appealing compactness of putting PWS and its 
request instances together, that compactness really doesn't buy 
anything, and invites confusion later.  As a stylistic matter (from 
one barely an adolescent in Smalltalk coding), Professor Johnson's 
remarks seemed salient.