Service-based Web Server

Abstract

The service based web server does very, very little on its own. All of its work is handled by services that tell it how it is configured, services that does all the work, and services that render the result. The constant interface between these services is passing WSGI requests over HTTP and a universal way to specify other methods of other services (URI).

Request Handling

The server is configured with a master configuration. This determines which paths map to which pages.

A page is a collection of components and the layout. The layout has slots that the rendered content of the components will be put into. There is also the universal and magical slot "first". Slots can also themselves be layouts with additional components comprising that. This allows two componets to be embedded side-by-side, for instance.

When a request comes in, it matches the path to the page. Then it starts rendering the page. First, it calls the "first" components, discarding the results. The first components may return a signal that the request is complete, for instance, if the component redirects 302 to a differnt page. Each component is rendered in parallel, as fast as is acceptable.

Then the server renders all of the components in the layout, as well as components within layouts within the layout. This is done as fast as possible in parallel. At this time, the layouts are also retreived.

When all of the components are completed, as well as the layouts, then the content is assembled. The result is then returned.

Configuration happens:

• At a global level, specifying global values passed as part of every request.
• At the path-page mapping level.
• At the page level, specifying constants and how parts of the path are interpreted to be part of the request.
• At the layout level. Some layouts require some configuration.
• For each component. There are set values and values that come from the request.