[Web-SIG] WSGI - alternative ideas

[Mark Nottingham]

+1

FWIW, I really like this; I'm going to code something up and see how it 
goes, but from a first look, this is *exactly* what the world needs.

My comments so far (based on revision 1.1):

  - in general, it would be helpful if references to external specs and 
constructs they define (e.g., CGI, HTTP, URI) had explicit links and 
section numbers, so we all are talking about the same things.

- in "The start_response() Callable", trailing CRs or LFs are 
forbidden; what about those inside the text? Multi-line HTTP headers 
are legal...

- it would be helpful if you gave distinguished names to the different 
callables flying around, and perhaps included an illustration; it gets 
confusing.

- could you talk a bit about the choice of using an environment 
dictionary for requests? In particular, I understand that CGI-style 
environment variables makes things easy for CGI implementations, 
potentially at the expense of others; why not do a list of tuples -- in 
the style that you describe for response headers?

Cheers,


On Aug 14, 2004, at 10:53 AM, Phillip J. Eby wrote:

> At 01:42 PM 8/14/04 -0400, angryhicKclown at netscape.net wrote:
>> Hi, I've just subscribed to this list, but I've read much of the 
>> archives. Python is in dire and immediate need of WSGI.
>>
>> I think WSGI needs to be essentially very similar to jonpy 
>> (jonpy.sf.net), except without the templating. Jonpy exposes an 
>> interface very similar to Java servlets, and can run on cgi, fastcgi, 
>> and mod_python by changing one line of code. WSGI, I believe, should 
>> be a higher-level interface than what has been currently outlined. 
>> For Python to succeed as a web language (and I believe that it will), 
>> it needs to support the following out of the box:
>>
>> - a clean servlet interface, see jonpy's Handler classes
>> - support for a multitude of different platforms easily
>> - sessions
>> - database connection pooling
>> - caching
>
> These needs are already served by dozens of Python web frameworks.  To 
> duplicate even *one* of these facilities in the WSGI specification 
> simply adds to the number of existing web frameworks, without fixing 
> anything.  WSGI is *intentionally* primitive, to minimize the number 
> of things that different frameworks disagree on.
>
> Unfortunately, *everybody* wants to write the "framework to end all 
> frameworks", but this always just results in the existence of 
> framework number N+1.  To really change the status quo, there *must* 
> exist something which is *not* a framework.
>
> WSGI can reach critical mass if a sufficient number of popular 
> frameworks and servers support it.  By contrast, a new framework must 
> successfully "recruit" *individual* users of existing frameworks who 
> have (potentially) already written quite a lot of code to that 
> framework's API.
>
> A new framework also threatens the value of the investments existing 
> framework authors have made, and therefore does not encourage their 
> participation in "cannibalizing" their work!
>
> _______________________________________________
> 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/