[Web-SIG] Is the size argument to the input-stream read method optional?

The PEP is unclear on this and should be clarified, IMO. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___

[Web-SIG] Thread-management middleware components?

Has anyone written any thread-management middleware components for WSGI? Many web applications need to run application code in separate threads. Often, the number of threads needs to be limited, either by throttling the rate of thread creation, or by dispatching requests to a thread pool. This is

[Web-SIG] When must applications call the WSGI start_response callable.

I'm a bit unclear about the timing of the start_response call. I think this is because the PEP is unclear, but perhaps I missed something. It doesn't appear that the PEP says when the start_response callable must be called. It gives several examples. In most, the callback is called when the appli

Re: [Web-SIG] When must applications call the WSGI start_response callable.

Jim Fulton wrote: > I'm a bit unclear about the timing of the start_response call. > I think this is because the PEP is unclear, but perhaps I missed > something. > > It doesn't appear that the PEP says when the start_response callable > must be called. It gives several examples. In most, the cal

Re: [Web-SIG] Thread-management middleware components?

Jim Fulton wrote: > Has anyone written any thread-management middleware components for WSGI? > Many web applications need to run application code in separate threads. > Often, the number of threads needs to be limited, either by throttling > the rate of thread creation, or by dispatching requests t

Re: [Web-SIG] Is the size argument to the input-stream read method optional?

Jim Fulton wrote: > The PEP is unclear on this and should be clarified, IMO. My experience in using implementations is many servers do not require the read size argument (they don't give a TypeError), but they block without it, or if you read past CONTENT_LENGTH. So it should probably be requi

Re: [Web-SIG] When must applications call the WSGI start_response callable.

On Dec 15, 2005, at 3:01 PM, Jim Fulton wrote: > Normally an application will call the start_response callable when the > application is called or when the result iterator is constructed, as > shown in the first 2 examples. An application, or more commonly, a > middleware component that provides it

Re: [Web-SIG] Thread-management middleware components?

Ian Bicking wrote: > Jim Fulton wrote: > >> Has anyone written any thread-management middleware components for WSGI? >> Many web applications need to run application code in separate threads. >> Often, the number of threads needs to be limited, either by throttling >> the rate of thread creation,

Re: [Web-SIG] When must applications call the WSGI start_response callable.

James Y Knight wrote: > On Dec 15, 2005, at 3:01 PM, Jim Fulton wrote: > >> Normally an application will call the start_response callable when the >> application is called or when the result iterator is constructed, as >> shown in the first 2 examples. An application, or more commonly, a >> middle

Re: [Web-SIG] When must applications call the WSGI start_response callable.

At 03:01 PM 12/15/2005 -0500, Jim Fulton wrote: >I'm a bit unclear about the timing of the start_response call. >I think this is because the PEP is unclear, but perhaps I missed >something. > >It doesn't appear that the PEP says when the start_response callable >must be called. It gives several ex

Re: [Web-SIG] When must applications call the WSGI start_response callable.

At 03:29 PM 12/15/2005 -0500, James Y Knight wrote: >I was led to believe this was a valid thing to do from the following >wording: > > (Note: the application must invoke the start_response() callable > > before the iterable yields its first body string, so that the > > server can send the headers

Re: [Web-SIG] When must applications call the WSGI start_response callable.

Ian Bicking wrote: > Jim Fulton wrote: ... >> Why do I want this? It appears that this would be needed to enable >> middleware components that manage application threads. I can imagine >> though that there aren't any existing servers that handle what I've >> suggested correctly. >> >> I do think

Re: [Web-SIG] Thread-management middleware components?

Jim Fulton wrote: >> Right now all threading and generally concurrency is handled by the >> server. Since it *has* to be handled by the server, > > > Why does it have to be handled by the server? Because most WSGI apps are blocking, so unless you want the server to be non-concurrent it has to

Re: [Web-SIG] Thread-management middleware components?

Ian Bicking wrote: > Jim Fulton wrote: > >>> Right now all threading and generally concurrency is handled by the >>> server. Since it *has* to be handled by the server, >> >> >> >> Why does it have to be handled by the server? > > > Because most WSGI apps are blocking, so unless you want the s