[Web-SIG] Regarding the WSGI draft

[Ben Sizer]

I've read through the draft and most of the messages on this list that 
followed it. However, I have a basic problem with it which I will 
attempt to summarise below.

The focus seems to be on making frameworks more portable. The abstract 
reads "This document specifies a proposed standard interface between web 
servers and Python web applications or frameworks, to promote web 
application portability across a variety of web servers." This is all 
well and good, but the implications from that point onwards are that 
we're firmly dealing with frameworks rather than applications. Phillip 
J. Eby has commented on Ian Bicking's blog that "at this stage, the 
benefits of WSGI are primarily for web *framework* authors, and web 
*server* authors, not web *application* authors. This is *not* an 
application API, it's a framework-to-server glue API."

This immediately strikes me as odd, because from my previous development 
experience frameworks are not that important. In fact, I'm heavily 
inclined to believe that Python only has a proliferation of frameworks 
because of the currently poor degree of higher level support for web 
development in general, and the various frameworks attempt to bridge 
that gap. Create better general web support for Python, and frameworks 
will only be necessary for the really heavy duty applications. Create 
the ability to make frameworks more portable, and all you do is 
encourage more people to develop more frameworks. Focusing on making 
life easier for framework developers is solving the wrong problem, in my 
opinion.

I come from an ASP and PHP background and generally speaking, a 
developer doesn't want or need a framework between their code and the 
web-scripting language when developing on those platforms. On the rare 
occasions that you do use a framework (such as PHP-Nuke) it's because 
you want to simplify high level activities like news management and user 
lists, and allow people to add content without needing to know HTML. By 
contrast Python's frameworks tend to address the trivial, low level 
things that should fall under the 'batteries included' philosophy that 
Python subscribes to.

The front page of this Python Web-SIG suggests, "pick a Web framework 
that already exists, make a functionality checklist from it, and add 
that functionality to a new webserver module." I think that's what is 
needed most of all - some sort of standard approach that new Python 
programmers can jump right in and use, which doesn't require choosing 
one of several different frameworks.

What I'd like to see is something mirroring the Python Database API. For 
instance, I might have to change "import MySQLdb" to "import pyPgSQL" 
but I know that 99% of the rest of the database code will work fine. As 
a web developer I would like to be able to change "import cgi" to 
"import mod_python" or "import fastcgi" and know that, if I follow a 
standard set of calls, I will have a simple and standard way of 
producing a web document. The standardised access to the output and 
input streams in the current draft is all well and good but there's 
little point in me making use of that abstraction if I still have to 
rely on extra modules for access to useful higher-level concepts such as:

- dispatching control flow based on the URI
- session management and cookies
- GET/query string parsing
- POST/form parsing
- ASP + PHP style templating

If these things are coming soon in future WSGI drafts, then great! But I 
got the impression that these features were being delegated out to the 
legion of frameworks.

I am aware that this all sounds very negative, and I don't mean to 
criticise the hard work that Phillip and others have put into this draft 
specification. I just worry that it diverts attention from what I 
consider to be the real issue facing Python on the web, which is making 
life easier for web application developers, not framework developers.

-- 
Ben Sizer