Main Entry: Co·man·che
Inflected Form(s): plural Comanche or Comanches
Etymology: American Spanish, from Southern Paiute kimmanci[ng]wi Shoshones, strangers
1 : a member of an American Indian people ranging from Wyoming and Nebraska south into New Mexico and northwestern Texas
2 : the Uto-Aztecan language of the Comanche people
3 : a new and improved PWS in Squeak
Investigator: Bolot Kerimbaev
Comanche is a new web server platform for Squeak. It utilizes a flexible pluggable framework for ease of reuse and rapid application development.
Basic functionality is provided in the core classes. Value added services are also included in the package (currently in beta 2).
An application unit, a squeaklet/servlet, is a module, which in turn may contain childred modules. Thus, an application is an assembly of modules that work together to provide the desired functionality.
Modules included with the standard Comanche release:
PwsModule (compatibility box for PWS, the web server in the current Squeak release)
Note: Swiki for Comanche is a separate package.
HttpConnectionQueue (or an analog) manages incoming connections, and sends them to the Module for processing. Since there can be multiple simultaneous connections, the root module should be thread-safe (other modules do not have to be thread safe if some locking mechanism is implemented).
HttpStream is an abstraction of the underlying HTTPSocket. Also, it maps into the low level socket representation on UNIX (but is not currently supported by Squeak). HttpRequest provides an additional layer of abstraction.
Comanche starts an HttpConnectionQueue processing loop.
Upon an incoming connection, HttpConnectionQueue creates a socket and spawns a Process to process the connection. The root module is started with module startOnSocket: socket.
An HttpRequest is created from the socket: First, an HttpStream is built on the socket, then the HttpRequest is created from the stream.
Module starts processing the request by module process: request.
Module performs some processing: self processBeforeModules: request.
The processing methods return a request (possibly modified), thus the next phase uses the return value of the previous call.
Module steps through its children, piping the result of one's processing on to the next. This pipe is short-curcuited if one of the modules indicates that the processing is completed.
Module performs some processing after all children (unless request is done): self processAfterModules: request.
Module returns the last returned request.
Back to the top | To the College of Computing
EduTech Institute | GVU Center