mso@oz.net wrote:
> 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.

I'd definitely love to see WSGIKit support Quixote well.  I don't want
WSGIKit to just implement the Webware API, I think there's room for it
to support all sorts of APIs and frameworks comfortably.

> 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).

It's the only one really included, just because it doesn't have a Real
Home.  wsgi-server can handle the WSGIUtils server, a "console" server
(which dumps one page to stdout), a CGI-generating "server" (creates a
CGI script), and used to support Twisted.  But Twisted web 2 got native
WSGI support, and I haven't tracked it down since then.  I would like to
include all other interesting servers (at least stubs for them), but I
don't think it's hard, and if it isn't hard I feel okay putting it off ;)

>   - The Session middleware may be usable.  It saves to files akin to
> DirMapping.

It's actually not that good, but I expect to integrate this session
middleware soon: http://www.saddi.com/software/py-lib/#Session

>   - 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.

Probably not applicable though potentially the URL parser could be used
to get to the Quixote parser, if that happened to be useful for deployment.

I was reluctant to do this at first, but I'm thinking a URL mapper
middleware would be useful, so you might do (in the configuration):

   urls['/webmail'] = config('path/to/webmail.conf')

Where webmail.conf contains all the configuration, including the type of
application.  For instance, this starts up a webkit app implicitly when
present in the configuration:

   webkit_dir = 'path/to/something'

So I'd imagine:

   quixote_root = 'my_app.root.object'

Or something like that.  There should be multiple ways to deploy and
compose applications in a single process.

Ideally I'd like to see one fairly general object publisher (/URL
parser) included in WSGIKit, where Quixote applications would either
subclass that publisher or pass in some configuration variables to get
it to act like Quixote's publisher.

>   - 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?

Even though I personally have no interest in backward compatibility for
Quixote, I wouldn't advocate this.  I don't believe backward
compatibility need be lost, except perhaps for deployment- and
configuration-related issues.

>   - 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?

You can potentially implement it at several levels, by adding
functionality to WSGIKit as a whole that is generally useful but also
specifically required for Quixote's existing functionality.

>   - What kind of compatibility objects would Request and Response be, and
> where would they be implemented?  Does a "qx_request" middleware make
> sense?

For Webware, I put the Servlet at the center -- it's the first thing
that is found, and the thing that actually understands WSGI.  So when
you call a servlet like:

   servlet(environ, start_response)

It creates Webware-compatible request and response objects.  When the
request is finished is makes sure the response flushes all its content
(which is normally cached).  Webware originally created request and
response objects right at the beginning, then found the servlet and
passed those in, so this was a change of design (but not one anyone
could notice from the outside).

Do Quixote objects that are published inherit from a single class?  If
not, then the publisher probably has to wrap the published object just
before passing off control to that object, and the wrapper would create
the request and response objects and make sure they get flushed properly
and whatnot.

>   - 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?

Again, WSGI and WSGIKit shouldn't require losing the spirit of Quixote
at all.  Maybe some more sophisticated things would be more easily
represented as raw WSGI middleware than some custom mechanisms that
might exist -- for instance, the URLParser hooks I added to Webware
weren't kept, because I just ended up replacing the functionality with
custom middleware.  But aesthetically it shouldn't be effected, and
depending on the publisher custom middleware may not be needed.
Deployment and some implementation *should* be affected, hopefully for
the better.

> 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....

I do allude to Whiskey on the wsgikit.org page ;)

--
Ian Bicking  /  ianb@colorstudy.com  / http://blog.ianbicking.org