[Web-SIG] WSGI in standard library

[Alan Kennedy]

[Alan Kennedy]
>>>3. If I had to pick one of the 3 you suggested, I'd pick the 
>>>last one, i.e. PJE's, because it fulfills exactly the criteria
>>>I listed

[Robert Brewer]
>>I have to disagree (having examined/unraveled it quite a bit recently,
>>to remove modpython_gateway's dependency on it). 

[Ian Bicking]
> I think it also tries to enforce a lot of the details of WSGI, and thus 
> guide a WSGI implementor into creating a compliant server.  

Well, I'm sure we all want our favourite server in the stdlib ;-)

But a few things have to happen first.

Priority #1: Make the requisite server a single standalone module.

Anticipating PJE's willingness to have WSGIRef included in the stdlib, 
I've taken the liberty of putting it all into one big file. And I think 
it looks pretty damn good: fully WSGI compliant, with code to represent 
every single aspect of the spec. Take a look for yourself: the file is 
attached. If the attachment doesn't make it to the list, I'll upload it 
somewhere.

But that doesn't mean the decision's over. It means that the bar has 
been raised. Anyone else who wants their module to be a contender has to 
get it all into the one file, i.e. eliminating all framework 
dependencies, etc.

Here's a few comments I put together about the three contenders that 
have been proposed so far. They're just my own comments from reading the 
code: feel free to treat them as the ravings of a madman if you so wish.

1. CherryPy server - 407 lines (non-code lines: ~80)

  - Depends on cherrypy, cherryp._cputil, cherryp.lib.httptools
  - Depends on cherrypy.config
  - Implements HTTP header length limit checking
  - Implements HTTP body length limit checking
  - Uses own logging handler
  - Subclasses SocketServer.BaseServer, not BaseHTTPServer.HTTPServer
    - Therefore does low-level socket mucking-about
  - Provides 2 server implementations
    - CherryHTTPServer
    - PooledThreadServer
  - Explicitly checks for KeyboardInterrupt exceptions
  - PooledThreadServer has clean shutdown through Queue.Queue messaging
  - Does not detect hop-by-hop headers
  - No demo application

My gut feeling: too complex, works to hard to be "production-ready", at 
the expense of readability.

2. Paste Server - 450 lines

  - Supports 100 continue responses
  - No imports from outside stdlib
  - Provides HTTPS/SSL server, with fallback if no SSL
  - Supports socket timeout
  - Demo application is (imported) paste.wsgilib.dump_environ
  - Does not detect hop-by-hop headers

My gut feeling: Ignores many parts of the WSGI spec (sendfile, strict 
error checking), supports unnecessary stuff for stdlib, i.e. Continue 
support, HTTPS.

3. WSGIRef_onefile.py - 660 lines

  - No imports from outside stdlib
  - Detects hop-by-hop headers
  - Has WSGI sendfile support
  - Has dedicated class to manage WSGI headers list as dictionary
  - Has builtin demo app

My gut feeling: WSGIRef is the sweetspot in terms of simplicity vs. 
usability. Covers all aspects of WSGI (which is what it was designed 
for, IIRC ;-)

The ball's in yizzir court now......

Alan.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wsgiref_onefile.py
Type: text/x-python
Size: 23564 bytes
Desc: not available
Url : http://mail.python.org/pipermail/web-sig/attachments/20060214/7d64639a/attachment-0001.py