At 05:06 PM 1/9/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-09 09:03:38 -0800, P.J. Eby said:
Hm. I'm not sure if I like that. The typical app developer really
shouldn't be yielding multiple body strings in the first place.
Wait; what? So you want the app developer to load a 40MB tal
At 04:39 PM 1/9/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-09 09:26:19 -0800, P.J. Eby said:
If wsgi.input offers any synchronous methods...
Regardless of whether or not wsgi.input is implemented in an async
way, wrap it in a future and eventually get around to yielding
it. Problem
On Jan 10, 2011, at 4:48 AM, chris.d...@gmail.com wrote:
> My reaction too. I've read this elsewhere on this list too, in other
> topics. A general statement that the correct way to make an
> efficient WSGI (1) app is to return just one body string.
>
> This runs contrary to everything I've ever
On Sun, 9 Jan 2011, Alice Bevan–McGregor wrote:
On 2011-01-09 09:03:38 -0800, P.J. Eby said:
Hm. I'm not sure if I like that. The typical app developer really
shouldn't be yielding multiple body strings in the first place.
Wait; what? So you want the app developer to load a 40MB talkcast M
On 2011-01-09 17:06:28 -0800, Alice Bevan-McGregor said:
On 2011-01-09 09:03:38 -0800, P.J. Eby said:
The elephant in the room here is that while it's easy towrite these
example applications so they don't block, in practicepeople read files
and do database queries and what not in their requests,
On 2011-01-09 09:03:38 -0800, P.J. Eby said:
Hm. I'm not sure if I like that. The typical app developer really
shouldn't be yielding multiple body strings in the first place.
Wait; what? So you want the app developer to load a 40MB talkcast MP3
into memory before sending it? You want to co
On 2011-01-09 09:26:19 -0800, P.J. Eby said:
By the way, I don't really see the point of the new sketches you're doing...
I'm sorry.
...as they aren't nearly as general as the one I've already done, but
still have the same fundamental limitation: wsgi.input.
You missed the point entirely, t
09.01.2011 22:56, P.J. Eby kirjoitti:
At 08:09 PM 1/9/2011 +0200, Alex Grönholm wrote:
Asynchronous applications may not be ready to send the status line as
the first thing coming out of the generator.
So? In the sketches that are the subject of this thread, it doesn't
have to be the first t
At 08:09 PM 1/9/2011 +0200, Alex Grönholm wrote:
Asynchronous applications may not be ready to send the status line
as the first thing coming out of the generator.
So? In the sketches that are the subject of this thread, it doesn't
have to be the first thing. If the application yields a futu
09.01.2011 19:03, P.J. Eby kirjoitti:
At 06:06 AM 1/9/2011 +0200, Alex Grönholm wrote:
A new feature here is that the application itself yields a (status,
headers) tuple and then chunks of the body (or futures).
Hm. I'm not sure if I like that. The typical app developer really
shouldn't be
At 04:25 AM 1/9/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
In the limit case, it appears that any WSGI 1 server could provide
an (emulated) async WSGI2 implementation, simply by wrapping WSGI2
apps with a finished version of the decorator in my sketch.
At 06:06 AM 1/9/2011 +0200, Alex Grönholm wrote:
A new feature here is that the application itself yields a (status,
headers) tuple and then chunks of the body (or futures).
Hm. I'm not sure if I like that. The typical app developer really
shouldn't be yielding multiple body strings in the f
On 2011-01-09 07:04:49 -0800,
exar...@twistedmatrix.com said:
I think this effort would benefit from more thought on how exactly
accessing this external library support will work. If async wsgi is
limited to performing a single read asynchronously, then it hardly
seems compelling.
Apologies
On 2011-01-09 07:04:49 -0800,
exar...@twistedmatrix.com said:
Don't say it if it's not true. Deferreds aren't tied to a reactor, and
Marrow doesn't appear to have anything called "deferred". So this
parallel to Twisted's Deferred is misleading and confusing.
It was merely a comparison to t
On 11:36 am, al...@gothcandy.com wrote:
On 2011-01-08 19:34:41 -0800, P.J. Eby said:
At 04:40 AM 1/9/2011 +0200, Alex Gr�nholm wrote:
09.01.2011 04:15, Alice Bevan�McGregor kirjoitti:
I hope that clearly identifies my idea on the subject. Since
async>>servers will /already/ be implementing the
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
In the limit case, it appears that any WSGI 1 server could provide an
(emulated) async WSGI2 implementation, simply by wrapping WSGI2 apps
with a finished version of the decorator in my sketch.
Or, since users could do it themselves, this would mea
On 2011-01-08 19:34:41 -0800, P.J. Eby said:
At 04:40 AM 1/9/2011 +0200, Alex Grönholm wrote:
09.01.2011 04:15, Alice BevanMcGregor kirjoitti:
I hope that clearly identifies my idea on the subject. Since
async>>servers will /already/ be implementing their own executors, I
don't>>see this as
On 2011-01-08 20:06:19 -0800, Alex Grönholm said:
I liked the idea of having a separate async_read() method in
wsgi.input, which would set the underlying socket in nonblocking mode
and return a future. The event loop would watch the socket and read
data into a buffer and trigger the callback w
09.01.2011 05:45, P.J. Eby kirjoitti:
At 06:15 PM 1/8/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
I've written the sketches dealing only with PEP 3148 futures, but
sockets were also proposed, and IMO the
At 06:15 PM 1/8/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
I've written the sketches dealing only with PEP 3148 futures, but
sockets were also proposed, and IMO there should be simple support
for obtain
At 04:40 AM 1/9/2011 +0200, Alex Grönholm wrote:
09.01.2011 04:15, Alice BevanMcGregor kirjoitti:
I hope that clearly identifies my idea on the subject. Since async
servers will /already/ be implementing their own executors, I don't
see this as too crazy.
-1 on this. Those executors are meant
09.01.2011 04:15, Alice Bevan–McGregor kirjoitti:
On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
I've written the sketches dealing only with PEP 3148 futures, but
sockets were also proposed, and IMO there should be simple support
for obtaining
On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
I've written the sketches dealing only with PEP 3148 futures, but
sockets were also proposed, and IMO there should be simple support for
obtaining data from wsgi.input.
I'm a bit unclear as to how
08.01.2011 23:16, P.J. Eby kirjoitti:
As a semi-proof-of-concept, I whipped these up:
http://peak.telecommunity.com/DevCenter/AsyncWSGISketch
It's an expanded version of my Coroutine concept, updated with sample
server code for both a synchronous server and an asynchronous one.
The synchro
As a semi-proof-of-concept, I whipped these up:
http://peak.telecommunity.com/DevCenter/AsyncWSGISketch
It's an expanded version of my Coroutine concept, updated with sample
server code for both a synchronous server and an asynchronous
one. The synchronous "server" is really just a decorato
25 matches
Mail list logo
