[Web-SIG] WSGI - alternative ideas

[Phillip J. Eby]

At 11:25 AM 8/14/04 -0700, Mark Nottingham wrote:
>+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...

In the next draft, I'll be drilling into these issues more, per Ian and 
Fredrik's comments earlier this week.  Specifically, I'm going to go into a 
lot more detail about *which* CGI variables are required to be available, 
and what headers must be supplied by the application object versus those 
which must be supplied by the server if not present.


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

Well, the only one that doesn't have an explicit name is the 'write' 
callable, and I can fix that by calling it "the 'write' callable".  Some 
editing should ensure that all callables are referred to with some kind of 
name nearby.


>- 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?

Because CGI variables aren't ordered.  If the request input were required 
to be HTTP headers, this would make it impossible for CGI, FastCGI and 
other gateways defined in terms of CGI to serve as valid WSGI implementations.