>Manlio Perillo wrote:
>> Brian Smith wrote:
>> For "non-blocking reads", given environ["wsgi.input"].read(64000,
>> min=8000):
>>
>> 1. If more than 64000 bytes are available without blocking, [64000] bytes
>> are returned.
>> 2. If less than 8000 bytes are available without blocking, then the
>>
Brian Smith ha scritto:
> Manlio Perillo wrote:
>> Brian Smith ha scritto:
>>> We already have standard mechanisms for doing something
>>> similar in WSGI: multi-threaded and multi-process WSGI
>>> gateways that let applications block indefinitely while
>>> letting other applications run.
>> Ok, bu
On 07/03/2008, Manlio Perillo <[EMAIL PROTECTED]> wrote:
> Is it true that Apache can spawn additional processes,
Yes, for prefork and worker MPM, but not winnt on Windows. See for
example details for worker MPM in:
http://httpd.apache.org/docs/2.2/mod/worker.html
> By the way, I know there i
Graham Dumpleton ha scritto:
> On 07/03/2008, Manlio Perillo <[EMAIL PROTECTED]> wrote:
>> Moreover with an asynchronous gateway it is possible to implement a
>> "middleware" that can execute an application inside a thread.
>>
>> This is possible by creating a pipe, starting a new thread, having
Graham Dumpleton ha scritto:
> [...]
>
> In part adding to what Brian is saying, you (Manlio) speak as if WSGI
> 2.0 is already somehow set in stone
Well, Philip J. Eby explicitly said that WSGI 2.0 exists only for
removing the use of start_response...
So I assume that it is already set in sto
Brian Smith ha scritto:
> Manlio Perillo wrote:
>> Brian Smith ha scritto:
>>> Manlio Perillo wrote:
Fine with me but there is a *big* problem.
WSGI 2.0 "breaks" support for asynchronous applications (since you
can no more send headers in the app iter).
>>> WSGI 1.0 doesn't gua
Graham Dumpleton ha scritto:
> On 06/03/2008, Manlio Perillo <[EMAIL PROTECTED]> wrote:
>> But I have to say that:
>>
>> 1) the asynchronous model is the "right" model to use to develope
>> robust and scalable applications (expecially in Python).
>
> No it isn't. It is one model, it is not n
Manlio Perillo wrote:
> Brian Smith ha scritto:
> > We already have standard mechanisms for doing something
> > similar in WSGI: multi-threaded and multi-process WSGI
> > gateways that let applications block indefinitely while
> > letting other applications run.
>
> Ok, but this is not the best so
On 07/03/2008, Manlio Perillo <[EMAIL PROTECTED]> wrote:
> Moreover with an asynchronous gateway it is possible to implement a
> "middleware" that can execute an application inside a thread.
>
> This is possible by creating a pipe, starting a new thread, having the
> main thread polling the pip
On 06/03/2008, Manlio Perillo <[EMAIL PROTECTED]> wrote:
> But I have to say that:
>
> 1) the asynchronous model is the "right" model to use to develope
> robust and scalable applications (expecially in Python).
No it isn't. It is one model, it is not necessarily the 'right' model.
The asyn
On 07/03/2008, Brian Smith <[EMAIL PROTECTED]> wrote:
> Graham Dumpleton wrote:
> > Anyway, WSGI 2.0 currently talks about returning a single
> > tuple containing status, headers and iterable. What if it
> > actually optionally allowed the response to itself be an
> > iterable, such that you co
Brian Smith ha scritto:
>
> [...]
>
> That idea doesn't really benefit Manlio's programs. Manlio's program is
> trying to say "use my thread for some other processing until some
> (external) event happens."
Right.
> We already have standard mechanisms for doing
> something similar in WSGI: mu
Graham Dumpleton wrote:
> This following idea may not make much sense, but baby keeping
> me up, its 4am and I am probably not going to get back to
> sleep until I get this idea out of my head now.
:) I think you need to have a serious discussion with the baby. Maybe if
she got a job she wouldn'
Phillip J. Eby ha scritto:
> At 01:11 PM 3/6/2008 +0100, Manlio Perillo wrote:
>> Manlio Perillo ha scritto:
>> > [...]
>> >
>> > I'm not sure that having two standards is the best solution, since it
>> > will complicate the implementation of a WSGI middleware.
>>
>> A correction: it should be WSGI
On 07/03/2008, Brian Smith <[EMAIL PROTECTED]> wrote:
> Manlio Perillo wrote:
> > Brian Smith ha scritto:
> > > Manlio Perillo wrote:
> > >> Fine with me but there is a *big* problem.
> > >>
> > >> WSGI 2.0 "breaks" support for asynchronous applications (since you
> > >> can no more send head
At 01:11 PM 3/6/2008 +0100, Manlio Perillo wrote:
>Manlio Perillo ha scritto:
> > [...]
> >
> > I'm not sure that having two standards is the best solution, since it
> > will complicate the implementation of a WSGI middleware.
>
>A correction: it should be WSGI gateway and not WSGI middleware.
On
Manlio Perillo wrote:
> Brian Smith ha scritto:
> > Manlio Perillo wrote:
> >> Fine with me but there is a *big* problem.
> >>
> >> WSGI 2.0 "breaks" support for asynchronous applications (since you
> >> can no more send headers in the app iter).
> >
> > WSGI 1.0 doesn't guarentee that all asynch
Manlio Perillo ha scritto:
> [...]
>
> I'm not sure that having two standards is the best solution, since it
> will complicate the implementation of a WSGI middleware.
A correction: it should be WSGI gateway and not WSGI middleware.
Manlio Perillo
Lawrence Oluyede ha scritto:
>> No, you are wrong.
>> WSGI *allows* an implementation to develope extensions.
>>
>> I'm complaining that WSGI 2.0 will break support for truly-async web apps.
>
> Correct me if I'm wrong. WSGI is great on paper and almost great in
> daily use. One of this peculia
> No, you are wrong.
> WSGI *allows* an implementation to develope extensions.
>
> I'm complaining that WSGI 2.0 will break support for truly-async web apps.
Correct me if I'm wrong. WSGI is great on paper and almost great in
daily use. One of this peculiarities in the "middleware extension
pat
Phillip J. Eby ha scritto:
> At 09:37 AM 3/6/2008 +1100, Graham Dumpleton wrote:
>> You probably need to explain the second half of that sentence a bit
>> better. From memory the WSGI 1.0 specification says that for an
>> iterable, the headers should be sent upon the generation of the first
>> non
Graham Dumpleton ha scritto:
> Let me get this right. You are complaining that the WSGI 2.0 would
> break your non standard extension which was never a part of the WSGI
> 1.0 specification to begin with.
>
No, you are wrong.
WSGI *allows* an implementation to develope extensions.
I'm complaining
At 09:37 AM 3/6/2008 +1100, Graham Dumpleton wrote:
>You probably need to explain the second half of that sentence a bit
>better. From memory the WSGI 1.0 specification says that for an
>iterable, the headers should be sent upon the generation of the first
>non empty string being yielded. How does
Let me get this right. You are complaining that the WSGI 2.0 would
break your non standard extension which was never a part of the WSGI
1.0 specification to begin with.
I also find it interesting that in the very early days you were
pushing very very hard for WSGI 2.0 to be specified and you had n
Brian Smith ha scritto:
Manlio Perillo wrote:
Fine with me but there is a *big* problem.
WSGI 2.0 "breaks" support for asynchronous applications
(since you can no more send headers in the app iter).
WSGI 1.0 doesn't guarentee that all asynchronous applications will work
either, because it al
25 matches
Mail list logo
