Refactor MoinMoin's request package to WSGI (only)

This page tries to summarize some suggestions that were (roughly) discussed elsewhere.

The general idea is to clean up MoinMoin.request, which currently supports all sorts of request methods (like cgi, fastcgi, wsgi, mod_python, twisted, standalone, cli). Maintaining and testing this code is a problem, as most developers only use 1 or 2 of these methods, but not all. Also, the code primarily lacks a clean separation of various bits of the request handling.

But before any work in this are is done, there needs to be a good plan, that covers everything from code to documentation.

Basics of moin as a WSGI application

MoinMoin is a WSGI application, implementing WSGI interface
optionally, there could be some WSGI middlewares, sitting between moin and speaking WSGI on both sides
- paste.cgitb_catcher for showing tracebacks via cgitb
- paste.evalexception for interactive debugging (not production)
- paste.gzipper gzip content compression
- sessions middleware
- http://www.wsgi.org/wsgi/Middleware_and_Utilities
at the top level, MoinMoin would ship
- a standalone server working like it is currently (internally serving the WSGI app)
- a (Fast)CGI-WSGI-adapter (copied from trac which forked flup)

For the user, nothing would change.

TODO

Code

moin already supports wsgi, so for the code it is primarily testing what is needed:

performance?
bugs?
missing features?
logging?
$/!\$ The code is not properly documented currently (for the user).

After going WSGI-only, some code maybe can be optimized / refactored more easily because of this.

The standalone server should be also switched to use WSGI for the wiki part, the static resources part has to be implemented somehow also.

Docs

throw away:
- (add MoinMaster: links)
keep/improve:
- (add MoinMaster: links)
add:
- we need some sort of migration docs / howtos / suggestions for moin users not already using wsgi and not knowing wsgi concepts. We can not expect that users change their servers completely, so we must show ways for what has been usually used in the past, see below.
- docs about dependencies

I do not see why docs would change a lot. Just the mod_py users will have to be advised to search for a wsgi-adaptor.

General notes about install docs:

throw away most old docs
create new docs, see NewDocs:
- desktop edition docs - how to get it working easily
- hello world wsgi app docs - we'll provide some testing wsgi app and this part of the docs just provides some pointers about how to make that app work
  - having hello world working will be required for getting moin support, everyone not getting that to work obviously does not need moin help, but help with his web server setup or wsgi adapter
- moin wsgi app docs - after having hello world work, getting moin wsgi app working should be easy and this part of the docs mostly deals with moin configuration, not web server configuration

any cgi (apache, IIS, lighttpd, ...)

moin.cgi could be changed to use wsgiref.handlers.CGIHandler.

Or, better for the users, Moin could use wsgiref itself and still be compatible to old CGI files.

For Python >= 2.3 , we can use wsgiref for py 2.3 and 2.4 and include it in moin distribution. After we require Python 2.5, this can be satisfied from the python stdlib and wsgiref can be removed from moin dist.

apache/ lighttpd via fastcgi or scgi

It makes sense to ship the modified flup that can be found in the trac distribution for various reasons (bugs in flup etc.)

apache / mod_python

There are various adapters that the users will be able to use, e.g. paste.modpython

apache / mod_wsgi

No change needed.

IIS / isapi or asp

Use isapi_wsgi, asp_wsgi, the shipped flup, etc. pp.

twisted

twisted_wsgi or twisted.web2 (twisted_wsgi2)?

standalone

We can probably replace our standalone "moin.py" server by a wsgiref.simpleserver.

For the static stuff, maybe use Luke Arno's "static" lib. static.Shock sounds interesting for mixed serving of static and dynamic content (and you maybe even could replace a wiki page by a static file in case you want to).

Open questions:

performance? Some people use standalone together with apache/squid and standalone supports misc. server implementations, e.g. a multithreaded one. how to do this with wsgiref?

Alternatively, we could use paste.httpserver - supporting ssl and multithreading.

Depending on paste for things that should work out of the box is not really sane IMHO. -- AlexanderSchremmer 2008-03-30 22:47:18

Or rather invoke: paster serve (using wsgiserver or wsgiutils_server)

cli

(unit testing)

paste.debug.testserver

Cf. paste fixture

Ideas

init scripts, see http://pythonpaste.org/script/
http://bitworking.org/news/Why_so_many_Python_web_frameworks see manage.py for a simple trick to use same python script for cgi and standalone

MoinMoin: FeatureRequests/WsgiRefactoring