Requirements for the MiniAppServer idea

So, while I'm trying to re-familiarize myself with the DBFSpy stack, I'm gonna capture some of the requirements ideas for the free-standing, Python-based mini-web-app-server idea that I mentioned in my last post. That entire string (free-standing, Python-based mini-web-app-server) is a bit much to type over and over again, it doesn't lend itself well to a meaningful acronym or abbreviation, and all of the logical names I can think of are already taken (Servelets, Applets, etc.), so I'm going to call it MiniAppServer, at least for now...

I mentioned that the idea came to me while I was working on a Python project at work. Without going into too much detail on that project (since I'm not sure if I can, legally), it basically boiled down to a free-standing Python-based service that would periodically query information from a remote logging service, potentially perform some sort of examination of the data returned, and respond if certain criteria were met (sending an email if our 404-count exceeded some threshold, for example).

One of the requirements for that project was that it be "configurable." There wasn't much in the way of definition for what "configurable" meant, so I started with the default of using the ConfigParser module's offerings to retrieve configuration information from a fairly typical configuration-file. While on the bus back home one night, it suddently occurred to me that if configuration-changes needed to be made, that would entail stopping the service, changing the configuration, and re-starting it. Admittedly, it might not happen in that order; given the shape of the code I came up with, altering the config-file, then restarting the service would have worked as well. But that started me thinking "what if there were a way to have the service also generate a web-based configuration-interface. Something that would allow IT staff to simply hit some URL and make changes to the configured values in real-time.

That was the impetus for MiniAppServer.

Whether the original idea for it's use becomes valid or not (the project at work was effectively cancelled, and I mothballed all of the code for it, following my previous recommendations as much as I could), I can certainly come up with some uses for such a thing for my own ends, so I'm adding it to my stack of projects.

So, what are MiniAppServer's requirements?

• It needs to be able to run on any machine (with a full Python installation being the only requirement);
• URLs should be (for anyting that isn't a static-file request/response) something along the lines of http://host:port/ObjectType/Action[/Format], where:

  ObjectType

  is the name of an object-type (perhaps a class, perhaps not)

  Action

  is some sort of action to be taken with the object-type. Some likely candidates include:
  

  • List - show a list of available items of the applicable object-type, probably as links to a View for the individual items;
  • View - Show a detailed view of a specific instance of an object-type;
  • Edit or Update - make and submit changes to one instance of a given object-type;
  • Create or New - create a new instance of an object-type (which may or may not be substantially different that the Edit form/view);
  • Delete - Delete a single instance of an object-type

  Format

  is (maybe) a format to return - XML, JSON, or whatever else. I cannot come up with a real use for this that justifies it to my satisfaction, and perhaps allowing a query-string (e.g., ?format=xml) instead would be better. I'll noodle on this for a while, I think;

  Some examples might include (for a User object-type):
  • http://localhost:8192/User/List
  • http://localhost:8192/User/View (this would need some sort of ID to be passed, maybe as an additional path element [.../View/USERID] or as a query-string)
  • http://localhost:8192/User/Edit (same comment as above)
  • http://localhost:8192/User/Create
  • http://localhost:8192/User/Delete
• It has to handle GET and POST requests, in order to support complete HTML form-interaction;
  • It needs to be able to handle "simple" POST submissions (e.g., text-only);
  • It will likely need to be able to handle binary upload-capable POST submissions as well, though that may not be an immediate requirement.
• It needs to be as small as possible - there's no point in having a whole lot of overhead for an application-server of this sort when a LAMP stack could just as easily be built with mod-python;
• At the same time, it needs to be highly extensible;
• It must be able to serve static files as well (for things like images, stylesheets and JavaScript);
• It should be something that could be set up to run as a service on a machine, or used as a local instance of an application.

Some "nice-to-have" features include:

• It should support as much of a Model-view-controller architecture/structure as is feasible;
• It would be neat if the entire application-site (if there are any non-Python files associated, at least) could be packaged up as a single zip-file or tarball;