[Web-SIG] Latest WSGI Draft
Phillip J. Eby
pje at telecommunity.com
Mon Aug 23 08:03:16 CEST 2004
At 12:24 AM 8/23/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 05:41 PM 8/22/04 -0500, Ian Bicking wrote:
>>>Phillip J. Eby wrote:
>>>>Alright. Let's make it 'wsgi.run_once'. Here's my attempt at a
>>>>``wsgi.run_once`` This value should be true if the server/gateway
>>>> expects (but does not guarantee!) that the
>>>> application will only be invoked this one time
>>>> during the life of its containing process.
>>>> Normally, this will only be true for a gateway
>>>> based on CGI (or something similar).
>>>Is there a reason it can't be guaranteed?
>>Is there a reason it *should* be guaranteed? :) The last time we had
>>this discussion (December?), I thought you'd decided that the standard
>>library's "atexit" facility was sufficient to cover your use case if a
>>guarantee was needed here. (I only just remembered the "atexit"
>>discussion, or I'd have suggested that as the solution instead of
>>introducing 'wsgi.last_call' a few days ago.)
>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 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.
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
>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?
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.
>>This would simplify the spec somewhat, since we wouldn't need to
>>introduce 'wsgi.extensions', and we can also drop the suggestion for
>>middleware authors to delete extensions. Middleware is simpler too, it
>>just changes what it needs to and moves on with life. :) We would just
>>have to add a section on how to build "safe" extensions to the spec.
>I do like the idea of simplifying this part of the spec. If it works.
>It's also something people can work out on their own. I expect the vast
>majority of these servers and applications to be open source, and if some
>pieces don't work together at first there's a feedback loop to fix that.
>Also, I don't think any of these discussions need to be resolved before
>this becomes a real PEP. There's going to be more discussion then (no
>matter how much we discuss now), and this discussion can just be part of
Alas, that's all too true. :(
More information about the Web-SIG