Google SoC 2008 - WSGI refactoring
Current status & todo items
I put together some pages where i try give an overview over the 2nd half of the GSoC project.
Status - current status of the code & some timetable to plan meetings/tasks
ToDo - a wildly (un)structured list of todo items and things to investigate
Intent of the project
The main goal for this SoC task is to merge the low-level request code for the different server types (standalone, cgi, fcgi, mod_python, twisted, etc.) and the lower levels of MoinMoin into a combination of WSGI-based Request/Response objects and a WSGI application. The various different server types will then be henceforth made available by WSGI adapters.
Design issues
Low level WSGI code
Since not every user of MoinMoin is going to run the application with a WSGI-ready server, some adapters have to be provided.
flup by Alan Saddi. Provides adapters/daemons for FCGI, SCGI and AJP.
WSGI ref. Already part of the Python 2.5 standard library and available as an additional package for 2.3 and 2.4. Provides a simple standalone WSGI server. This can be dropped when MoinMoin should go 2.5+ only.
modpython_wsgi.py by Eli Collins. A small wrapper for mod_python to provide WSGI support.
Here is some information on how you use WSGI in Twisted (Matrix).
We need to decide, which ones to bundle with MoinMoin and which ones to document for deploying admins. Proposal:
Interface |
proposed handling |
CGI |
moin.cgi, quite easy to write |
FastCGI |
moin.fcgi with bundled flup (or derivative like in Trac) |
Standalone |
bundled wsgiref with some additions for static content |
mod_python |
drop direct support, provide documentation on how to setup |
twisted |
drop direct support, provide documentation on how to setup |
mod_wsgi |
emphasize this in the documentation, could become an easy way to deploy MoinMoin |
Request
In a first short discussion with my mentor ArminRonacher, we agreed on creating a new API on the Request object, instead of porting the old one to WSGI method by method. As a base for such a redesigned Request object, the power of existing WSGI toolkits could be leveraged. There are several toolkits available, one of them being Werkzeug, which is developed by Armin himself in the course of the pocoo project. It provides a concise general purpose WSGI toolbox, including Request/Response objects and several small utilities and WSGI apps (a router for example).
Compatibility
To keep the code working while refactoring and transparently support legacy code, a compatibility wrapper will be used. It will be based on and mimic the behaviour of the current 'request'-object. Then during the refactoring, the methods can be replaced successively with calls to the new API.
Refactoring Request
In the current MoinMoin codebase a lot of functionality and application specific code is implemented on the Request object (for example RequestBase.run) My proposal would be, to keep the new Request object free of application specific code and put this into a WSGI application. Following is a list of responsibilities found in the current request object and how this could be handled in the new API:
Responsibility |
how to handle |
incoming/outgoing headers |
provided by the code in werkzeug, should stay on the Request-object (obviously) |
sending files |
WSGI filewrapper if available or some file-streaming generator |
GET/POST/Cookies |
see incoming/outgoing headers |
HTTP status codes |
can be set via werkzeugs Response-objects or throwing HTTP exceptions |
URL routing |
werkzeug already has a routing middleware in place, but perhaps it's already overkill to use it. what are the actual requirements for URL routing except static files (actions as part of the url, xmlrpc which is quite decoupled, etc.) |
debug environment |
testing and debugging can be made easy by just providing mock 'environ' and 'start_response' (see WSGI spec) for use from the commandline |
timing log |
|
authentication |
|
spider checks |
|
theme loading |
|
unique id generation |
|
page name normalization/decoding |
|
redirected output |
|
finishers |
|
![/!\](/moin_static19/modernized/img/alert.png "/!\"){kind=small}
TODO: Watch http://video.google.com/videoplay?docid=-3733345136856180693 to get a better understanding of API design criterias
Documentation
TODO