[Web-SIG] Latest WSGI Draft

[Ian Bicking]

Phillip J. Eby wrote:
>> atexit was a different discussion.
> 
> 
> Really?  I thought you were asking for something to be called upon exit 
> as a way of addressing this exact same issue: i.e., the app knowing when 
> to clean up after itself.

I'm not really that concerned about the cleanup with CGI.  I don't think 
it's that important that the application is used only once in a CGI 
context, but then I don't think it matters much the other way either. 
But I don't see any advantage for some other server to set run_once when 
it *thinks* this is the last request (but doesn't know it for sure).  In 
fact, I don't even see a reason for wsgi.run_once if the server *knows* 
this is the last request, except in the case where the last request is 
also the first request (i.e., CGI).

I just think wsgi.run_once and CGI are the same, and there's no reason 
to state it any differently than that.  And CGI guarantees your 
application won't be rerun.  Or the spec could simply be silent on the 
matter, without stressing the issue one way or the other.

>>   I don't know if there's a reason it should be guaranteed, but then I 
>> don't know if there's any situation where it wouldn't be guaranteed.  
>> I can't imagine it being used outside of a CGI context, and it is 
>> guaranteed for CGI.
> 
> 
> Fine.  I just don't like it being anything other than a heuristic.  
> Suppose I'm running acceptance tests?  My CGI runner will say "you're 
> being run only once", except then I'll run it again when the acceptance 
> test tests another input.  But, I want the acceptance test to test the 
> operation of the application when it's in "cgi mode", effectively.

If you're running multiple unit tests in a single process, you aren't in 
CGI mode, and you shouldn't set that key.  You're in some other mode. 
If CGI mode really matters, the only test that is accurate is one where 
you are actually launching a separate process.

> So, what I'm saying is that any app that I wrote, I would want 
> 'run_once' or 'last_run' or whatever it was called to *not* be a 
> guarantee of never running again, but only a suggestion to "rig for 
> infrequent running".  If my code *actually* relied upon it being a 
> guarantee, then testing scenarios are hosed.
>
>> I can see that working for extensions to the request, but what about 
>> extensions to the response?  E.g., some mod_python extension could 
>> allow for internal redirects -- a useful feature that won't fit into 
>> WSGI.
> 
> 
> Really?  Why not?  Let's say that mod_python provides the function, the 
> app calls it, doesn't call 'start_response', and doesn't return an 
> iterator.  What does middleware do?  Well, presumably it does nothing.  
> Definitely it does nothing if it's an output transformer, or if it just 
> adds things to the request.  So, where's the problem?

Well, let's say mod_python adds two extensions.  One is to do a local 
redirect, the other is to do a recursive call.  The local redirect would 
be in wsgi.extensions (if it existed), but the recursive call would not. 
  With wsgi.extensions, the middleware would eliminate the local 
redirect, and the application would be forced to use the recursive call 
and write out the result of that.  Which is what you would want, because 
then the middleware would have an opportunity to modify the output.

I still can't think of a good way to define wsgi.extensions or give 
rules for what should go in there.  I can see some case for it, but 
since it's vague I don't think it should be included in the spec. 
There's room to add it later if it turns out to be important.

> For other kinds of responses, the behavior is as I outlined before: if 
> the extension is replacing the existing functionality, one should have 
> to call a function to get it, passing in the existing functionality 
> (e.g. environ or start_response) so that the extender can verify that 
> critical functions aren't being mediated by middleware.

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