[Web-SIG] WSGI Webware progress
ianb at colorstudy.com
Sun Oct 3 06:18:44 CEST 2004
I've made quite a bit of progress with the WSGI port of Webware, running
two real applications I've written under it, without any significant
changes to the applications (except for an import statement or two).
The applications weren't written with WSGI in mind, so they didn't limit
themselves to things that seemed simple under WSGI. OTOH, I wrote both
of them, and I only use a subset of the Webware API.
The Webware portion of this remains fairly minimal, mostly some simple
classes that translate the WSGI environment and general system to the
In the process, I've made some reusable middleware that is
Webware-neutral, but implements some of Webware's functionality (and I
layer them in roughly this order):
* httpexceptions; catches particular exceptions and turns them into HTTP
responses (e.g., HTTPMovedPermanently, HTTPNotFound, etc). In a way I
wish this was standard. However, the other middleware doesn't use this
(though some of my Webware code does).
* recursive; allows applications to forward to other URLs and to make
recursive calls to include other URLs. These URLs have to be under the
location where recursive is used.
* session; implements sessions. The persistence is simple and doesn't
take concurrency into account (yet), but the basic structure seems
correct to me.
* urlparser; this takes a URL and finds an application based on it.
Currently it looks in a single directory, parses out the next part, and
finds the application associated. Subdirectories turn into other
urlparser instances. Finds .py modules, and looks for "application"
(which is a ready-made application), or module.module_name, where the
object must be called before it is ready to act as an application (in
Webware's case, this is a class, instances of which are WSGI
applications). Also serves up static files, like .css, .html, etc.
* wsgilib; a number of generic functions for use with WSGI. Right now
* Cookie parser: get_cookies
* Something to add a finalizing function to an iterator: add_close
* A way to run a request in a fake environment, for interactive
debugging and testing: interactive
* An error response creator (for 404 messages, etc): error_response
* An application-builder for on-disk files: send_file
I still need to do more testing, and write some unit tests for these
middleware. But progress has gone well, and implementing a real-world
framework on WSGI seems very doable. This is a more aggressive use of
WSGI than many framework ports may make; a simpler porting technique
would be to take the whole framework and find a single entry point,
letting the framework keep all its URL parsing and other code. I'm
doing this refactoring in part because I think it's the right direction
for Webware, moreso than it's the best or easiest way to port a framework.
Comments and suggestions welcome. The code is located at
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG