On May 22, 2008, at 6:21 PM, Manlio Perillo wrote:
That way, the server doesn't have to rewrite the request, and the
application doesn't need to know how to interpret the files.*
parameters.
How to interpret the files.* parameters is not really a problem.
It's a problem for a portable app
On May 22, 2008, at 4:51 AM, Manlio Perillo wrote:
I'm reading the PEP 342, and I still think that this will not work
as I want for Nginx (where I have no control over the "scheduler").
In fact the PEP 342 says:
"""However, if it were possible to pass values or exceptions *into* a
generator a
On May 21, 2008, at 1:34 PM, Manlio Perillo wrote:
Instead, the spec recommends that async servers pre-read the
request body
before invoking the app (either by default or as a configurable
option).
This is the best solution most of the time (but not for all of the
time), especially if t
This is the third draft of my proposed extensions for better
supporting WSGI apps on asynchronous servers. The major changes since
the last draft are as follows:
* The title and abstract now accurately reflect the scope of the
proposal.
In addition, the extensions are now in the namespac
On May 12, 2008, at 5:07 PM, James Y Knight wrote:
Surely you need DNS lookup to make a socket connection? Do you mean
to provide that in an external library via a threadpool?
No, I don't mean to, because I don't care enough to bother. But if
you or someone else did, you'd be free to.
Yo
On May 12, 2008, at 12:18 PM, James Y Knight wrote:
There are other issues. How do you do a DNS lookup? How do you get
process completion notification? Heck, how do you run a process?
These are valid questions that I'm not attempting to address with this
proposal. So maybe the title of my
On May 12, 2008, at 12:45 AM, Ionel Maries Cristian wrote:
On Mon, May 12, 2008 at 3:25 AM, Christopher Stawarz <[EMAIL PROTECTED]
> wrote:
On May 11, 2008, at 7:05 PM, Phillip J. Eby wrote:
For this to work, you're going to need this to take the wsgi.input
object as a paramet
On May 12, 2008, at 12:01 AM, Ionel Maries Cristian wrote:
My thinking is that the server *creates* the environ dictionary, so
it can just keep a reference to it and update it as needed. Is
middleware allowed to replace environ with another dict instance
before passing it to the applicatio
On May 11, 2008, at 7:05 PM, Phillip J. Eby wrote:
At 06:15 PM 5/11/2008 -0400, Christopher Stawarz wrote:
Non-blocking Input Stream
~
The ``x-wsgiorg.async.input`` variable provides a non-blocking
replacement for ``wsgi.input``. It is an object with one method
This is a revised version of my AWSGI proposal from last week. While
many of the details remain the same, the big change is that I'm now
proposing a set of extensions to standard WSGI, rather than a separate
specification for asynchronous servers.
The updated proposal is included below. I
On May 7, 2008, at 10:59 PM, Christopher Stawarz wrote:
However, the problem remains that, even though an asynchronous
server can implement the write() callable and wsgi.input as required
by the WSGI spec, they effectively can't be used by applications,
since they involve potent
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
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 May 7, 2008, at 4:44 AM, Manlio Perillo wrote:
Moreover I don't see any readons to have a revc method instead of
read.
I just wanted to emphasize that its behavior is socket-like, not file-
like. It could be called read as long as its behavior is made clear
to application developers.
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 k
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, unless it has to be. It was effe
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 interf
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. t
(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 for
19 matches
Mail list logo
