[Web-SIG] Re: Bill's comments on WSGI draft 1.4

[Ian Bicking]

Phillip J. Eby wrote:
> At 06:07 PM 9/1/04 -0700, Bill Janssen wrote:
> 
>> 1.  The "environ" parameter must be a Python dict: I think subclasses
>> should be allowed.  A true subclass supports all methods of its
>> ancestors, so the rationale presented in the back of the PEP for
>> excluding them doesn't hold water.  I think the appropriate check
>> would be to see if the returned class is a subclass of the "dict"
>> class.  That is, "isinstance(e, dict)" should return True.
> 
> 
> Paradoxically, allowing subclasses eliminates the usefulness of allowing 
> subclasses.  Presumably, the purpose of using a subclass is to provide 
> some extended behavior, e.g. as an attribute/method, or as a byproduct 
> of requesting particular keys or values.  In both cases, these extended 
> behaviors would be destroyed the minute that a piece of middleware 
> decides to use its *own* dictionary subclass.

I agree strongly with you on this.  Subclassing built in types is almost 
only useful for showing off clever tricks and distracting people who 
want to change the language.  Code constantly contains assumptions that 
you can recreate built in types from their components, and then you lose 
the subclass.  I also don't see any advantage, beyond theoretical.  Any 
attempt to leverage a subclass is just as likely to cause problems as be 
a help.

>> 9.  There should be a non-optional way of indicating the URL scheme,
>> whether it is "http", "https", or "ftp".  I'd suggest "wsgi.scheme" in
>> the environ.
> 
> 
> I rather like this, although I don't at all see how FTP gets into this.  
> What the heck would CGI variables for FTP look like, I wonder?  Anyway, 
> it's handy for "http" and "https" at the very least.  I'd prefer 
> "wsgi.url_scheme" for the name, though, as it's otherwise a somewhat 
> ambiguous name.

This sounds good to me too.  I wanted HTTPS=on to be required, but 
wsgi.url_scheme would be more general anyway.

It's pretty easy to imagine translating FTP to CGI variables, really. 
The requested URL (SCRIPT_NAME+PATH_INFO) is the file you are getting or 
putting, the REQUEST_METHOD is maybe GET or PUT (or maybe STOR and RETR, 
but GET and PUT would be more natural).  Most of the other commands map 
to WeDAV methods.  Obviously the server has to keep track of some state, 
but typically that state is boring to the application anyway.  But 
that's all an aside.  I can imagine mailto as well, when you pipe email 
to your application.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org