Design for the MiniAppServer idea

The design for MiniAppServer feels like it ought to be fairly simple, given what I'm thinking is a typical development-case:

• Create a MiniAppServer instance, with various properties, including:
  • Host name;
  • Port;
  • A document-root, if desired;
  • A top-level request-routing mechanism (something that can handle application-ish endpoints and/or static-file requests/responses);
  • Any application-ish endpoint-handlers needed;
  • Any error-handling endpoint-handlers needed;
• If necessary, add/register any non-standard endpoint-handlers;
• If necessary, add/register any standard handlers for errors, etc.;
• Call MiniAppServer.serve_forever()

When a request is recieved by the MiniAppServer instance, it gets handled as follows:

1. The request (plus it's socket and whatever other information/objects are needed by a BaseRequestHandler instance) are passed to the application's top-level routing object.
2. That routing object examines the request made, looking for a match based on:
   1. Registered application-ish endpoints;
   2. Static-file endpoints;
   3. Other endpoints? I can't think of any that make sense, but I can't rule out the possibility...
   If a match is found, the request (and everything associated) is passed to a new instance of the appropriate endpoint class.
3. The endpoint-handler does whatever it needs to do, generating whatever output it needs to generate, and returns that response.
   • If an error is encountered, then the request (etc.) should be passed to the registered error-handling endpoint-handler, if there is one;
   • If there is not a specific error-handling endpoint, a simple, raw response should be returned with the appropriate HTTP code);

Given all of this, what I'm expecting (at least as of this writing) is an object-structure something like so:

IsApplication (nominal interface)

Provides interface requirements and type-identioty for objects that can provide MiniAppServer-like functionality. This is specifically called out becuse there would otherwise be circular references between MiniAppServer and HasApplication.

HasApplication (nominal abstract class)

Provides an Application property for derived objects, which should be an instance implementing IsApplication.

IsEndpoint (nominal abstract class)

Provides baseline functionality, interface requirements and type-identity for objects that can act as endpoints for a MiniAppServer instance. Endpoint definitions should be derived from this and SocketServer.BaseRequestHandler, though I'm not sure whether I want to make IsEndpoint a subclass of SocketServer.BaseRequestHandler directly, or just have it check to make sure that instances derived from it are also derived from SocketServer.BaseRequestHandler.

BaseRouter (nominal abstract class), or

Router (class, extensible)

Ultimately, I'm expecting that a running MiniAppServer instance will require a router-object: something that the recieved requests are handed off to, that then spins off an appropriate IsEndpoint-derived instance to handle the request and return results to the client. Whether this should be a class in and of itself, or a nominal abstract class that developers should derive their own classes from, I'm not sure yet. There are potential advantages to both, and I'm very much on the fence as to which way to go with it.

ErrorEndpoint (class, extensible, derives from IsEndpoint and HasApplication)

An IsEndpoint-derived class that will be handed control over an incoming request when/if an error occurs.

FileEndpoint (class, final, derives from IsEndpoint and HasApplication)

An IsEndpoint-derived class that will handle looking up static files for responses to requests that don't get caught by a functional IsEndpoint instance first.

MiniAppServer (class, extensible, implements IsApplication)

The class that's actually responsible for generating and starting a server instance.

Working my way from the top of this list down seems a rational approach, at least for now...