Those who were at PyCon remember two of the most popular talks, the
PyWebOff and WSGIKit.  I'd like to port Quixote to WSGIKit, and am
wondering if anyone else is doing this or would like to participate.  I've
been mulling it over ever since PyCon, and the mod_scgi bug has given me a
practical reason to pursue it.  AMK has been doing something along these
lines, and I saw on the web somewhere that somebody wrote a WSGI-compliant
version of Quixote a few months ago.

The talks are summarized in my PyCon article
    http://linuxgazette.net/113/orr.html
At the time of writing, I mistook several of Ian's comments regarding
WSGIKit as referring to WSGI itself, so I'd better unravel them first.

WSGI (Web Server Gateway Interface) is Python PEP 333
    http://python.org/peps/pep-0333.html
which describes a standard way for a Python webserver adapter to
communicate with a Python web application.  This would allow
Quixote/Webware/Zope ("frameworks") to share adapters (which I could have
used now to deal with the mod_scgi bug), and vice-versa giving webadmins
more frameworks compatible with their favorite software.  WSGI also has
the concept of "middleware" akin to Unix pipelines -- modules that handle
sessions, URL parsing, or anything else.

WSGIKit is Ian Bicking's version of Webware that uses WSGI, as well as
reusable WSGI components and middlewares.
    http://wsgikit.org/

I looked briefly at the source and saw it's not a simple straightforward
task.
  - wsgikit.cgiserver seems to be the only adapter, akin to
quixote.servers.cgi_server .  Nothing fast enough for production use
unless you believe in FastCGI (which I don't).
  - The Session middleware may be usable.  It saves to files akin to
DirMapping.
  - The URL Parser middleware is prob'ly not applicable since we don't
look for specific URLs in the filesystem, and we must allow ._q_traverse
to be overridden at any "directory" level.
  - Should parts of Quixote should be dropped in favor of
WSGIKit-compatibility routines?
  - Would parts of the Quixote API have to change in incompatible ways?
  - At what level do we implement it?  As a quixote.server frontend?  As a
Publisher replacement?  What about applications with custom
Publisher/Session/Request subclasses?
  - What kind of compatibility objects would Request and Response be, and
where would they be implemented?  Does a "qx_request" middleware make
sense?
  - Can we support 100% of existing Quixote 2.0 applications?  Or should
we target a subset?
  - How far can we change it before it's not "Quixote" anymore?

I'm thinking of calling it Jack, as in "Jack is compatible with Quixote"
or "Brian can build websites with Jack".  The name Whiskey (WSGI) first
came to mind but I don't like whiskey. :)  I do like cider and Cider Jack
is my favorite, so....