[Web-SIG] WSGI in standard library
Ian Bicking
ianb at colorstudy.com
Tue Feb 14 22:45:06 CET 2006
Robert Brewer wrote:
> Alan Kennedy wrote:
>
>>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.
>
>
> I have to disagree (having examined/unraveled it quite a bit recently,
> to remove modpython_gateway's dependency on it). The server class seems
> simple enough, but the handlers module is IMO horribly convoluted,
> mostly to support too many options: async vs. threaded, origin and
> non-origin servers, various HTTP versions, file sending hooks, etc.
> There are simply too many variables involved in building a WSGI handler
> appropriate for your environment; trying to do that by subclassing
> wsgiref.handlers.* results in extremely complicated and slow code.
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. But in the
process it creates a framework that has to be correctly used, so it's
swapping a well-understood set of bugs (doing something you aren't
supposed to with WSGI) for a different set (using the handler incorrectly).
paste.lint is reasonably good at checking WSGI compliance (those parts
that are actually detectable) without caring about what your code
actually looks like. I think it is easier to use, with largely the same
effect.
For the actual server a framework seems unnecessary, as there will only
be two servers in the standard library (I assume) -- CGI and HTTP (and
hopefully HTTPS will be easy to build off of HTTP).
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG
mailing list