Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread P.J. Eby
At 10:18 PM 4/8/2010 +0200, Manlio Perillo wrote: Suppose I have an HTML template file, and I want to use a sub request. ... ${subrequest('/header/'} ... The problem with this code is that, since Mako will buffer all generated content, the result response body will contain incorrect data. It w

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread Manlio Perillo
P.J. Eby ha scritto: > At 08:06 PM 4/8/2010 +0200, Manlio Perillo wrote: >> What I'm trying to do is: >> >> * as in the example I posted, turn Mako render function in a generator. >> >> The reason is that I would lite to to implement support for Nginx >> subrequests. > > By subrequest, do you

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread P.J. Eby
At 08:06 PM 4/8/2010 +0200, Manlio Perillo wrote: What I'm trying to do is: * as in the example I posted, turn Mako render function in a generator. The reason is that I would lite to to implement support for Nginx subrequests. By subrequest, do you mean that one request is invoking anothe

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread Manlio Perillo
P.J. Eby ha scritto: > At 05:40 PM 4/8/2010 +0200, Manlio Perillo wrote: >> With WSGI 2.0 we will end up with: >> >> - WSGI 1.0, a full featured protocol, but with hard to implement >> middlewares >> - WSGI 2.0, a simple protocol, with more easy to implement middlewares >> but without support f

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread P.J. Eby
At 05:40 PM 4/8/2010 +0200, Manlio Perillo wrote: With WSGI 2.0 we will end up with: - WSGI 1.0, a full featured protocol, but with hard to implement middlewares - WSGI 2.0, a simple protocol, with more easy to implement middlewares but without support for some "advanced" applications Let

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread Manlio Perillo
P.J. Eby ha scritto: > At 04:59 PM 4/8/2010 +0200, Manlio Perillo wrote: > [...] >> There should be a sample WSGI 2.0 implementation for CGI, and a sample >> WSGI 1.0 -> 2.0 adapter. >> >> This adapter should be able to support the coroutine example, >> > http://paste.pocoo.org/show/199202/ >> but

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread P.J. Eby
At 04:59 PM 4/8/2010 +0200, Manlio Perillo wrote: Aaron Watters ha scritto: > someone remind me: where is the canonical WSGI 2 spec? http://wsgi.org/wsgi/WSGI_2.0 > I assume there is a way to "wrap" WSGI 1 applications > without breaking them? Or is this the regex-->re fiasco > all over again?

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread Manlio Perillo
Aaron Watters ha scritto: > someone remind me: where is the canonical WSGI 2 spec? http://wsgi.org/wsgi/WSGI_2.0 > I assume there is a way to "wrap" WSGI 1 applications > without breaking them? Or is this the regex-->re fiasco > all over again? > start_response can be implemented by a function

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread P.J. Eby
At 04:08 PM 4/8/2010 +0200, Manlio Perillo wrote: Hi. Some time ago I objected the decision to remove start_response function from next version WSGI, using as rationale the fact that without start_callable, asynchronous extension are impossible to support. Now I have found that removing start_r

Re: [Web-SIG] WSGI and start_response

2010-04-08 Thread Aaron Watters
someone remind me: where is the canonical WSGI 2 spec? I assume there is a way to "wrap" WSGI 1 applications without breaking them? Or is this the regex-->re fiasco all over again? -- Aaron Watters --- On Thu, 4/8/10, Manlio Perillo wrote: > From: Manlio Perillo > Subject: [Web-SIG] WSGI a

[Web-SIG] WSGI and start_response

2010-04-08 Thread Manlio Perillo
Hi. Some time ago I objected the decision to remove start_response function from next version WSGI, using as rationale the fact that without start_callable, asynchronous extension are impossible to support. Now I have found that removing start_response will also make impossible to support corouti