At 01:07 PM 10/6/2007 +1000, René Dudfield wrote:
>I think 'streaming' is good for speeding up web pages when processing
>takes a while.
>
>I'll explain why...
>
>Say your page takes 0.2 seconds to process.
>
>If you wait until 0.2 seconds is up, then the first bytes that will
>come to the browser
I think 'streaming' is good for speeding up web pages when processing
takes a while.
I'll explain why...
Say your page takes 0.2 seconds to process.
If you wait until 0.2 seconds is up, then the first bytes that will
come to the browser will arrive in at least 0.2 seconds. Whereas if
you send d
At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote:
>That's to much chicken/egg for my tastes. All you are really saying is
>that the CGI model covers the majority of 'common' use cases. I don't
>know of anyone who would disagree with this. But as things stand all
>wsgi-ish implementations which aim to
On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:34 PM 10/5/2007 +0100, Robin Bryce wrote:
> >Is there a means to support a non blocking read on wsgi.input ?
>
> No. Some ideas have been proposed, but nobody has shown a practical
> scenario where it is useful.
>
> For it to be usef
At 07:38 PM 10/5/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > I still don't see how this is *useful*. What will the application *do*
> > with this information?
>
>As an example (not tested) SQLAlchemy can implements a
>RequestSingletonPool, that is the equivalend of ThreadSing
Phillip J. Eby ha scritto:
> At 05:14 PM 10/5/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
>> >> Phillip J. Eby ha scritto:
>> >> > In other words, those flags were to support legacy frameworks
>> detecting
>> >> > that the
At 05:34 PM 10/5/2007 +0100, Robin Bryce wrote:
>Is there a means to support a non blocking read on wsgi.input ?
No. Some ideas have been proposed, but nobody has shown a practical
scenario where it is useful.
For it to be useful, you would have to have an asynchronous server
that is interleav
At 05:14 PM 10/5/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
> >> Phillip J. Eby ha scritto:
> >> > In other words, those flags were to support legacy frameworks detecting
> >> > that they were in an incompatible hosting envir
At 11:57 AM 10/5/2007 -0300, Rob De Almeida wrote:
>Phillip J. Eby wrote:
>>I mean that you can't write a WSGI 2.0 application using a single
>>generator function, because it has to return a tuple, not an
>>iterator. This will discourage people from thinking "yield" is a
>>good way to build up
On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> 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
Manlio Perillo ha scritto:
> Ian Bicking ha scritto:
>> [...]
>>> Ok, here is more useful definition.
>>>
>>> If wsgi.asynchronous evaluates to true, then the WSGI application
>>> *will* be executed into the server main process cycle and thus the
>>> application execution *will* be interleaved (s
Ian Bicking ha scritto:
> [...]
>> Ok, here is more useful definition.
>>
>> If wsgi.asynchronous evaluates to true, then the WSGI application
>> *will* be executed into the server main process cycle and thus the
>> application execution *will* be interleaved (since this is the only
>> way to su
Manlio Perillo wrote:
> Phillip J. Eby ha scritto:
>> At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
>>> Phillip J. Eby ha scritto:
In other words, those flags were to support legacy frameworks detecting
that they were in an incompatible hosting environment. However, IIUC,
there
Phillip J. Eby ha scritto:
> At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > In other words, those flags were to support legacy frameworks detecting
>> > that they were in an incompatible hosting environment. However, IIUC,
>> > there is no such existing frame
Phillip J. Eby wrote:
> I mean that you can't write a WSGI 2.0 application using a single
> generator function, because it has to return a tuple, not an
> iterator. This will discourage people from thinking "yield" is a
> good way to build up their output, instead of using a StringIO or
> ''.j
At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > In other words, those flags were to support legacy frameworks detecting
> > that they were in an incompatible hosting environment. However, IIUC,
> > there is no such existing framework that could meaningfully use t
At 12:36 PM 10/5/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> > Yep, but another argument in favor of getting rid of as much
> > statefulness from the protocol as we can. Making the status and headers
> > part of the return value entirely eliminates the question of whe
Phillip J. Eby ha scritto:
> 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 stat
Phillip J. Eby ha scritto:
> [...]
> Yep, but another argument in favor of getting rid of as much
> statefulness from the protocol as we can. Making the status and headers
> part of the return value entirely eliminates the question of when
> they're going to get written, and whether they can be
DiPierro, Massimo wrote:
> here are some unique features:
> 1) full web based development, deployment and management of applications, no
> more shell commands (unless you want them)
Good. Zope seems to have moved away from this, which is a shame...
> 2) built-in ticketing system to report bugs t
20 matches
Mail list logo
