[Web-SIG] Regarding the WSGI draft

[Mark Nottingham]

Hi Ben,

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.

Contrast this with databases, which are for the most part a commodity; 
you can plug in different databases because they all have the same 
conceptual model of how a database works.

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.

That being the case, WSGI provides something that's incredibly 
valuable; as long as it maintains the right level of abstraction, it 
allows application frameworks to avoid worrying about the details of a 
particular server implementation.

I'm pleased as punch with it, because it lets me avoid doing that when 
I write my own application framework (details forthcoming ;).

Cheers,


On Aug 26, 2004, at 11:30 AM, Ben Sizer wrote:

> 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
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: 
> http://mail.python.org/mailman/options/web-sig/mnot%40mnot.net
>

--
Mark Nottingham     http://www.mnot.net/