[Web-SIG] Regarding the WSGI draft

[Bob Kimble]

On Thursday 26 August 2004 03:46 pm, Ben Sizer wrote:
> Mark Nottingham wrote:
> > I understand where you're coming from, but I think we're in a different
> > situation here. There are a lot of different ways
> > that you can construct an application framework; there is no "one true
> > way," because people have varying requirements for a Web application.
>
> ...
>
> > There has been some progress towards convergence on a common view of
> > what a Web application is, but I still think we have a ways to go, and
> > much to learn, before any one application framework can declare victory.
>
> Although what you say makes sense on the surface, the fact remains that
> technologies such as ASP and PHP are popular and useful because they
> present a simple and standard interface to the user, whether that user
> is writing a 4 line script, a small application, or a large framework
> upon which to base other applications. With Python you seem stuck with
> two equally unappealing options: slow CGI if you want a simple script,
> where simple is relative since you need to fool around with os.environ,
> printing your own headers, etc - or a complex and idiosyncratic
> framework if you want anything non-trivial, but which is often just as
> complex as PHP straight out of the box, except with a much smaller user
> base and generally less documentation.
>
> For example, you know that $_GET[varName] is going to be the standard
> way of accessing a querystring variable in PHP. Yet in Python it could
> be part of a request.form dictionary, or
> cgi.parse_qs(os.environ['QUERY_STRING']), or
> modpython.util.parse_qs(req.parsed_uri[7]), etc. Yet we know that query
> strings are part of the RFC2396 standard, so why not have a standard
> module or interface to present to the user?
>
> I don't see any good reason for this sort of variance, except that
> there's a bias towards accommodating these existing frameworks rather
> than enabling simpler applications of the future, and which I think is a
> symptom of the problem rather than part of the solution.

I have been reading this thread for a while now, and I haven't commented 
because I have done absolutely no web development using Python. However, 
Mark's comments strike me as being dead on. I'm used to the Java Servlet API, 
which creates an API for servlets and JSP pages. The fact that there are 
several high quality application servers that all support this API suggests 
to me that creating something similar for Python makes a lot of sense. I have 
written JSP's and servlets and run them under Tomcat, but I know that I could 
just as easily run them under WebSphere, WebLogic, JRun, or any others that 
support the API. It seems to me that creating a similar API for Python would 
be terrific. Of course, somebody would also have to write an application 
server to support the API, but I suspect some of the existing frameworks 
could be revamped to support it. Anyway, that's my 2 cents. I would love to 
see something similar to Tomcat and the Java Servlet API for Python.