[Web-SIG] WSGI in standard library

[Ian Bicking]

Alan Kennedy wrote:
>> I'm not set on "production" quality code, but I think the general 
>> sentiment against that is entirely premature.  The implementations 
>> brought up -- CherryPy's 
>> (http://svn.cherrypy.org/trunk/cherrypy/_cphttpserver.py) and Paste's 
>> (http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py) and 
>> wsgiref's 
>> (http://cvs.eby-sarna.com/wsgiref/src/wsgiref/simple_server.py?rev=1.2&view=markup) 
>> are all pretty short.  It would be better to discuss the particulars. 
>> Is there a code path in one or more of these servers which you think 
>> is unneeded and problematic?
> 
> 
> A few points.
> 
> 1. My opinion is not relevant to whether/which WSGI server goes into the 
> standard library. What's required is for someone to propose to 
> python-dev that a particular WSGI server should go into the standard 
> library. I imagine that the response on python-dev to the proposer is 
> going to be along the lines of "Will you be maintaining this?" If/when 
> python-dev is happy, then it'll go into the distribution.
> 
> 2. What's wrong with leaving the current situation as-is, i.e. the 
> available WSGI implementations are listed on the WSGI Moin page
> 
> http://wiki.python.org/moin/WSGIImplementations

I think a WSGI HTTP server is considerably more useful than
SimpleHTTPServer, for a whole bunch of reasons.  With a WSGI HTTP
server, I see little reason for anyone to use any of the other
Simple*Server implementations (unless perhaps they are using async
processing, which WSGI does not facilitate, but I think is doable with
SimpleHTTPServer).

> 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
> 
>  - It's pretty much the simplest possible implementation, meaning it's 
> easiest to understand.

In part this is because it uses the other parts of wsgiref, which the
other servers do not.

>  - It's based on the existing *HttpServer hierarchy

All three share this property.

>  - It's got a big notice at the top saying """This is both an example of 
> how WSGI can be implemented, and a basis for running simple web 
> applications on a local machine, such as might be done when testing or 
> debugging an application.  It has not been reviewed for security issues, 
> however, and we strongly recommend that you use a "real" web server for 
> production use."""

And of course this is one of the easiest features to port ;)


But anyway, maybe the standard library isn't the right place for any of
these, maybe it wasn't the right place for SimpleHTTPServer (though it's
hard to actually argue that, since in practical terms SimpleHTTPServer
has been very successful).

But we could also just create a stand-alone package that provides just
an HTTP server, and reference that from wherever appropriate (including
the standard library documentation).  Right now the standard library
documentation doesn't often reference external packages.  I don't know
if there's any real reason for that.  I will posit that no, there is no
good reason that the stdlib documentation shouldn't link directly to
projects (at least in certain situations).

I think we have enough implementations to take from to make such a
canonical HTTP package, at least within the scope of threaded HTTP
implementations based on SimpleHTTPServer.  Though then there's the
whole Twisted question -- but right now packaging and scope make it hard
to actually use Twisted in these same situations.  But given a specific
API, at least that would give Twisted a clear target so that instead of
"from httpserver import HTTPServer" you'd do "from twisted.httpserver
import HTTPServer" and then you'd be running under Twisted (ignoring
scenarios where Twisted does more than HTTP serving, which is out of
scope here).

Of course, then you could say "lets create a multi-protocol app server
package" integrating perhaps portions of Flup, an HTTP server, and a
couple other things (but there's not a whole lot else I imagine going 
into this stuff).  And then the scope starts to match Twisted, except 
perhaps with a simplification that you'd only handle 
request/response-style protocols with blocking WSGI-style responders.

Then you could say, hey, isn't WSGI meant to keep us from having to do
these combined efforts, because multiple packages are okay if they all
implement the same standard?

Then you could say, sure, but it also means that we can combine packages
on a different timescale and structure than higher-level frameworks 
(WSGI applications), waiting until the time is ripe, and maybe the time 
is ripe.  It feels lame (to me) to tell people to use one package or 
another as they switch from HTTP to SCGI to whatever.

Then-you-could-saying'ly y'rs...

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