Phillip J. Eby ha scritto:
> [...]
>> There is a problem here: a WSGI gateway is not allowed to send headers
>> until the app_iter yields a non empty string or the iterator is exausted.
>
> Argh. You're right. I forgot about that bit. It has been a few too
> many years since I worked on the sp
At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote:
>On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
> > >There is a problem here: a WSGI gateway is not allowed to send headers
> > >until the app_iter yields a non empty string or the
At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> >> There is a problem here: a WSGI gateway is not allowed to send headers
> >> until the app_iter yields a non empty string or the iterator is exausted.
> >
> > Argh. You're right. I forgot about that bit.
On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote:
> >On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
> > > >There is a problem here: a WSGI gateway is not allowed to send
At 10:20 PM 10/4/2007 +1000, Graham Dumpleton wrote:
>On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote:
> > >On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > > At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
> > > > >T
Phillip J. Eby ha scritto:
> At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > [...]
>> >> There is a problem here: a WSGI gateway is not allowed to send headers
>> >> until the app_iter yields a non empty string or the iterator is
>> exausted.
>> >
>> > Argh.
Ian Bicking ha scritto:
> PJE wants to talk about WSGI 2. That's cool; I remind everyone that
> there's a page to bring up issues you might want to discuss for 2.0:
> http://wsgi.org/wsgi/WSGI_2.0
>
> Feel free to add to, or discuss, issues on that page...
>
I'll write my ideas here:
1) start
Graham Dumpleton ha scritto:
> [...]
>> The idea was to allow an application to change its mind about the
>> headers until it had committed to writing data. That is, to allow
>> the application to do error handling for as long as possible before
>> the server has to do it.
>
> But once you have c
Phillip J. Eby ha scritto:
> [...]
>
> WSGI 2.0 does not have a start_response() callable in the first place,
> so none of these apply.
>
I thought that the current WSGI 2.0 draft was only, indeed, a draft.
>
> [...]
>> 4) the environ dictionary should have a new WSGI-defined variable:
>>
At 03:47 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Ian Bicking ha scritto:
> > PJE wants to talk about WSGI 2. That's cool; I remind everyone that
> > there's a page to bring up issues you might want to discuss for 2.0:
> > http://wsgi.org/wsgi/WSGI_2.0
> >
> > Feel free to add to, or discuss, is
At 03:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
> >> Phillip J. Eby ha scritto:
> >> > [...]
> >> >> There is a problem here: a WSGI gateway is not allowed to send headers
> >> >> until the app_iter yields a non e
At 04:10 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Graham Dumpleton ha scritto:
> > [...]
> >> The idea was to allow an application to change its mind about the
> >> headers until it had committed to writing data. That is, to allow
> >> the application to do error handling for as long as possible
Phillip J. Eby ha scritto:
> [...]
>
>> However I have to admit that developing a full asynchronous application
>> is not easy, notably when we have to interact with a database and a
>> transaction.
>
> Right - in practice, there is not enough of a common async API for
> Python to make it practic
Phillip J. Eby ha scritto:
> At 04:10 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> Graham Dumpleton ha scritto:
>> > [...]
>> >> The idea was to allow an application to change its mind about the
>> >> headers until it had committed to writing data. That is, to allow
>> >> the application to do err
At 05:00 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Your are making a critical decision here.
>You are lowering the level of WSGI to match the level of average WSGI
>middlewares programmers.
No, we're just getting rid of legacy cruft that's hard to support
correctly. There's a big difference.
At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> >
> > WSGI 2.0 does not have a start_response() callable in the first place,
> > so none of these apply.
> >
>
>I thought that the current WSGI 2.0 draft was only, indeed, a draft.
That's correct. But elimi
Phillip J. Eby ha scritto:
> At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > [...]
>> >
>> > WSGI 2.0 does not have a start_response() callable in the first place,
>> > so none of these apply.
>> >
>>
>> I thought that the current WSGI 2.0 draft was only, indee
Phillip J. Eby ha scritto:
> [...]
>> I have read a lot of archived messages, and all I have seen are
>> *discussions* about asynchronous extensions, but no working
>> implementations.
>
> Because nobody came up with anything particularly useful. While it's
> possible to have generic extensions
At 05:54 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote:
> >> Phillip J. Eby ha scritto:
> >> > It's always the case that a WSGI application can be paused after it
> >> > yields data, even in WSGI 1.0.
> >>
> >> I was not
At 06:07 PM 10/4/2007 +0200, Manlio Perillo wrote:
>For nginx mod_wsgi I'm planning to add support to blocking
>application,executing them in a thread (*but* there will be only one
>thread per process, and the entire result will be buffered).
>
>Threaded execution will be disabled by default, and c
On Oct 4, 2007, at 11:55 AM, Phillip J. Eby wrote:
> At 05:00 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> Your are making a critical decision here.
>> You are lowering the level of WSGI to match the level of average WSGI
>> middlewares programmers.
>
> No, we're just getting rid of legacy cruft
At 06:37 PM 10/4/2007 +0200, Manlio Perillo wrote:
>To make an example (not tested), suppose that a WSGI application keeps a
>global counter (as a thread specific data).
>
>When a new request arrives, the counter is reset to 0, and its value is
>incremented for every iteration.
>
>With all the exis
Phillip J. Eby ha scritto:
> [...]
>> and existing
>> WSGI implementations does not interleave the iteration, as far as I know.
>
> Nothing in the spec stops them from doing so - indeed, they're
> *encouraged* to do so:
>
> http://www.python.org/dev/peps/pep-0333/#middleware-handling-of-block-b
Phillip J. Eby ha scritto:
> At 06:07 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> For nginx mod_wsgi I'm planning to add support to blocking
>> application,executing them in a thread (*but* there will be only one
>> thread per process, and the entire result will be buffered).
>>
>> Threaded execut
Phillip J. Eby ha scritto:
> At 06:37 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> To make an example (not tested), suppose that a WSGI application keeps a
>> global counter (as a thread specific data).
>>
>> When a new request arrives, the counter is reset to 0, and its value is
>> incremented for
At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote:
>But why you are against adding a new environ value (not necessary named
>wsgi.asynchronous), that will explicitly state if the WSGI server will
>interleave the WSGI application?
Why do you think it's useful?
_
Phillip J. Eby ha scritto:
> At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> But why you are against adding a new environ value (not necessary named
>> wsgi.asynchronous), that will explicitly state if the WSGI server will
>> interleave the WSGI application?
>
> Why do you think it's useful?
hello everybody...
please do not shoot me! I know you don't think you need a new web framework but
please give me the benefit of the doubt (I teach a class on Web Frameworks at
DePaul University):
http://mdp.cti.depaul.edu/examples
Why?
here are some unique features:
1) full web based developm
On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >But once you have called start_response() you cant call it a second
> >time to change the values
>
> You can, as long as you pass in the exception info -- because an
> exception is the only legitimate reason to change the values.
Okay, fo
At 09:03 AM 10/5/2007 +1000, Graham Dumpleton wrote:
>Too early for me to be thinking straight and work it out for myself,
>but does this all help in making it simpler or more obvious what the
>cleanup requirements are for a generator. Ie., correct use of
>try/except/finally around yield and purpos
At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote:
> >> But why you are against adding a new environ value (not necessary named
> >> wsgi.asynchronous), that will explicitly state if the WSGI server will
> >> interle
On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:03 AM 10/5/2007 +1000, Graham Dumpleton wrote:
> >Too early for me to be thinking straight and work it out for myself,
> >but does this all help in making it simpler or more obvious what the
> >cleanup requirements are for a generator
On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
> >Phillip J. Eby ha scritto:
> > > At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote:
> > >> But why you are against adding a new environ value (not necessary named
> > >> wsgi.asynchronou
Graham Dumpleton wrote:
> On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
>>> Phillip J. Eby ha scritto:
At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote:
> But why you are against adding a new environ value (not necessary nam
34 matches
Mail list logo
