Ionel Maries Cristian ha scritto:
This is a very interesting initiative.
However there are few problems:
- there is no support for chunked input - that would require having
support for readline in the first place, also, it should be the
gateway's business decoding the chunked input.
Christopher Stawarz ha scritto:
On May 7, 2008, at 4:20 AM, Graham Dumpleton wrote:
2008/5/7 Manlio Perillo [EMAIL PROTECTED]:
With your solution it seems that writing middlewares will not became
more
easy.
Part of what I was trying to say was that this needn't be exposed to
middlewares,
On May 6, 2008, at 8:51 PM, Ionel Maries Cristian wrote:
- there is no support for chunked input - that would require having
support for readline in the first place,
Why is readline a requirement for chunked input? Each chunk specifies
its size, and the application receiving a chunk just
On Wed, 2008-05-07 at 14:00 -0400, Christopher Stawarz wrote:
On May 7, 2008, at 4:20 AM, Graham Dumpleton wrote:
2008/5/7 Manlio Perillo [EMAIL PROTECTED]:
With your solution it seems that writing middlewares will not
became more
easy.
Part of what I was trying to say was that
On May 7, 2008, at 3:35 PM, Duncan McGreggor wrote:
It's my understanding that greenlets are python, not C. Are you
thinking
of tasklets in stackless?
The version for CPython is a C extension module. Have a look at the
comments in
http://svn.red-bean.com/bob/greenlet/trunk/greenlet.c
On Wed, May 7, 2008 at 10:00 PM, Christopher Stawarz
[EMAIL PROTECTED] wrote:
On May 6, 2008, at 8:51 PM, Ionel Maries Cristian wrote:
- there is no support for chunked input - that would require having
support for readline in the first place,
Why is readline a requirement for chunked
On May 7, 2008, at 5:36 PM, Ionel Maries Cristian wrote:
The way I see it asynchronous wsgi is just a matter of deciding how
to handle the input asynchronously - a asynchronous input wsgi
extension specification.
Another crucial element is the ability to perform non-blocking I/O on
other
Christopher Stawarz ha scritto:
(I'm new to the list, so please forgive me for making my first post a
specification proposal :)
Browsing through the list archives, I see there's been some
inconclusive discussions on adding better support for asynchronous web
servers to the WSGI spec. Since
On May 5, 2008, at 10:08 PM, Graham Dumpleton wrote:
If write() isn't to be returned by start_response(), then do away with
start_response() if possible as per discussions for WSGI 2.0.
I think start_response() is necessary, because the application may
need to yield for I/O readiness (e.g.
On May 6, 2008, at 6:17 AM, Manlio Perillo wrote:
I'm glad to know that there are some other people interested in
asynchronous application, do you have seen my extensions to WSGI in
my module for Nginx?
Yes, I have, and I had your module in mind as a potential provider of
the AWSGI
This is a very interesting initiative.
However there are few problems:
- there is no support for chunked input - that would require having support
for readline in the first place, also, it should be the gateway's business
decoding the chunked input.
- the original wsgi spec somewhat has some
(I'm new to the list, so please forgive me for making my first post a
specification proposal :)
Browsing through the list archives, I see there's been some
inconclusive discussions on adding better support for asynchronous web
servers to the WSGI spec. Since such support would be very useful
2008/5/6 Christopher Stawarz [EMAIL PROTECTED]:
(I'm new to the list, so please forgive me for making my first post a
specification proposal :)
Browsing through the list archives, I see there's been some
inconclusive discussions on adding better support for asynchronous web
servers to
13 matches
Mail list logo
