After a weekend of experimentation with several asynchronous frameworks
including gevent, tornado and twisted (and writing one myself too), and
these are my findings so far:
- asynchronous socket implementations vary wildly across different
frameworks
- gevent is the fastest, tornado comes
On Jan 16, 2011, at 10:49 PM, Alex Grönholm wrote:
After a weekend of experimentation with several asynchronous frameworks
including gevent, tornado and twisted (and writing one myself too), and these
are my findings so far:
- asynchronous socket implementations vary wildly across
17.01.2011 06:47, Glyph Lefkowitz kirjoitti:
On Jan 16, 2011, at 10:49 PM, Alex Grönholm wrote:
After a weekend of experimentation with several asynchronous frameworks
including gevent, tornado and twisted (and writing one myself too), and these
are my findings so far:
- asynchronous socket
, web-sig@python.org
Sent: Tuesday, January 11, 2011 2:28:55 AM
Subject: Re: [Web-SIG] PEP 444 feature request - Futures executor
On Tue, Jan 11, 2011 at 10:40 AM, Timothy Farrell
tfarr...@owassobible.org wrote:
- Original Message -
From: P.J. Eby p...@telecommunity.com
To: Timothy
At 09:11 PM 1/10/2011 -0600, Timothy Farrell wrote:
PJ,
You seem to be old-hat at this so I'm looking for a little advise as
I draft this spec. It seems a bad idea to me to just say
environ['wsgi.executor'] will be a wrapped futures executor because
the api handled by the executor can and
- Original Message -
From: P.J. Eby p...@telecommunity.com
To: Timothy Farrell tfarr...@owassobible.org, web-sig@python.org
Sent: Friday, January 7, 2011 2:14:20 PM
Subject: Re: [Web-SIG] PEP 444 feature request - Futures executor
There are some other issues that might need
Here's what I've mutated Alex Grönholm's minimal middleware example
into: (see the change history for the evolution of this)
https://gist.github.com/771398
A complete functional (as in function, not working ;) async-capable
middleware layer (that does nothing) is 12 lines. That, I
Warning: this assumes we're running on bizzaro-world PEP 444 that
mandates applications are generators. Please do not dismiss this idea
out of hand but give it a good look and maybe some feedback. ;)
--
Howdy!
I've finished touching up the p-code illustrating my idea of using
generators
As a quick note, this proposal would signifigantly benefit from the
simplified syntax offered by PEP 380 (Syntax for Delegating to a
Subgenerator) [1] and possibly PEP 3152 (Cofunctions) [2]. The former
simplifies delegation and exception passing, and the latter simplifies
the async side of
On 2011-01-07 09:47:12 -0800, Timothy Farrell said:
However, I'm requesting that servers _optionally_ provide
environ['wsgi.executor'] as a futures executor that applications can
use for the purpose of doing something after the response is fully sent
to the client. This is feature request is
I made a few errors in that massive post...
At 12:00 PM 1/8/2011 -0500, P.J. Eby wrote:
My major concern about the approach is still that it requires a fair
amount of overhead on the part of both app developers and middleware
developers, even if that overhead mostly consists of importing and
At 05:39 AM 1/8/2011 -0800, Alice BevanMcGregor wrote:
As a quick note, this proposal would signifigantly benefit from the
simplified syntax offered by PEP 380 (Syntax for Delegating to a
Subgenerator) [1] and possibly PEP 3152 (Cofunctions) [2]. The
former simplifies delegation and
On Sat, Jan 8, 2011 at 6:26 AM, Alice Bevan–McGregor
al...@gothcandy.com wrote:
Warning: this assumes we're running on bizzaro-world PEP 444 that mandates
applications are generators. Please do not dismiss this idea out of hand
but give it a good look and maybe some feedback. ;)
--
Howdy!
At 01:24 PM 1/8/2011 -0500, Paul Davis wrote:
For contrast, I thought it might be beneficial to have a comparison
with an implementation that didn't use async might look like:
http://friendpaste.com/4lFbZsTpPGA9N9niyOt9PF
Compare your version with this one, that uses my revision of Alice's
On 9 January 2011 12:16, Alice Bevan–McGregor al...@gothcandy.com wrote:
On 2011-01-08 09:00:18 -0800, P.J. Eby said:
(The next interesting challenge would be to integrate this withGraham's
proposal for adding cleanup handlers...)
class MyApplication(object):
def __init__(self):
On 2011-01-06 20:49:57 -0800, P.J. Eby said:
It would be helpful if you addressed the issue of scope, i.e.,
whatfeatures are you proposing to offer to the application developer.
Conformity, predictability, and portability. That's a lot of y's.
(Pardon the pun!)
Alex Grönholm's post
On 2011-01-06 10:15:19 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... writes:
Er, for the record, in Python 3 non-blocking file objects return None when
read() would block.
-1
I'm aware, however that's not practically useful. How would you detect
from within the WSGI 2
On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote:
:: Clear separation of narrative from rules to be followed. This allows
developers of both servers and applications to easily run through a
confomance check list.
+1
:: Isolation of examples and rationale to improve readability of the core
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by incorporatingthe
most common (1%) of features most often relegated to middlewareor
functional helpers.
Note that nearly every application-friendly feature you add will
increase the burden on both
On 2011-01-07 01:08:42 -0800, chris.dent said:
... this particular goal [reduction of reimplementation / NIH] could
cover a large number of things from standardized query string
processing (maybe a good idea) to filters (which I've already expressed
reservations about).
So this goal seems
At 12:39 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
Earlier in this post I illustrated a few that directly apply to a
commercial application I am currently writing. I'll elaborate:
:: Image scaling would benefit from multi-processing (spreading the
load across cores). Also, only one
At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by
incorporatingthe most common (1%) of features most often
relegated to middlewareor functional helpers.
Note that nearly every
No, otherwise I'd totally go for the surrogateescape approach. Heck,
I'd still go for it if it were possible to write a surrogateescape
handler for 2.6, and require that a PEP 444 server register one with
Python's codec system. I don't know if it's *possible*, though,
hopefully someone
Alice Bevan–McGregor al...@... writes:
I don't understand why you want a yield at this level. IMHO, WSGI
needn't involve generators. A higher-level wrapper (framework,
middleware, whatever) can wrap fd-waiting in fancy generator stuff if
so desired. Or, in some other environments,
Cc: al...@gothcandy.com, web-sig@python.org
Sent: Thursday, January 6, 2011 11:30:11 PM
Subject: Re: [Web-SIG] PEP 444 / WSGI 2 Async
On Thu, Jan 6, 2011 at 8:49 PM, P.J. Eby p...@telecommunity.com wrote:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Tossing the idea around all day
There has been much discussion about how to handle async in PEP 444 and that
discussion centers around the use of futures. However, I'm requesting that
servers _optionally_ provide environ['wsgi.executor'] as a futures executor
that applications can use for the purpose of doing something after
If it's optional, what's the benefit for the app of getting it through
WSGI instead of through importing some other standard module? The API
of the executor will require a lot of thought. I worry that this
weighs down the WSGI standard with the responsibility of coming up
with the perfect executor
if an application called
executor.shutdown(). This doesn't seem difficult to my tiny brain.
- Original Message -
From: Guido van Rossum gu...@python.org
To: Timothy Farrell tfarr...@owassobible.org
Cc: web-sig@python.org
Sent: Friday, January 7, 2011 11:59:10 AM
Subject: Re: [Web-SIG] PEP 444
On Fri, Jan 7, 2011 at 9:47 AM, Timothy Farrell wrote:
There has been much discussion about how to handle async in PEP 444 and
that discussion centers around the use of futures. However, I'm
requesting that servers _optionally_ provide environ['wsgi.executor']
as a futures executor that
On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... writes:
I don't understand why you want a yield at this level. IMHO, WSGI
needn't involve generators. A higher-level wrapper (framework,
middleware, whatever) can wrap fd-waiting in fancy generator stuff if
so
On 2011-01-07 08:10:43 -0800, P.J. Eby said:
At 12:39 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
:: Image scaling would benefit from multi-processing (spreading
theload across cores). Also, only one sacle is immediately
requiredbefore returning the post-upload page: the thumbnail. The
There is practically no reason for doing so; esp. considering that I've
managed to write a 2k/3k polygot server that is more performant out of the
box than any other WSGI HTTP server I've come across and is far simpler in
implementation than most of the ones I've come across with roughly
- Original Message -
From: P.J. Eby p...@telecommunity.com
To: Timothy Farrell tfarr...@owassobible.org, web-sig@python.org
Sent: Friday, January 7, 2011 2:14:20 PM
Subject: Re: [Web-SIG] PEP 444 feature request - Futures executor
This seems like a potentially good way to do it; I
Alice Bevan–McGregor al...@... writes:
On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... writes:
I don't understand why you want a yield at this level. IMHO, WSGI
needn't involve generators. A higher-level wrapper (framework,
middleware, whatever) can
On 2011-01-07 12:42:24 -0800, Paul Davis said:
Is the code for this server online? I'd be interested in reading through it.
https://github.com/pulp/marrow.server.http
There are two branches: master will always refer to the version
published on Python.org, and draft refers to my rewrite.
On 2011-01-07 13:21:36 -0800, Antoine Pitrou said:
Ok, so, WSGI doesn't already involve generators. QED.
This can go around in circles; by allowing all forms of iterable, it
involves generators. Geneators are a type of iterable. QED right
back. ;)
Right, that's why I was suggesting you
On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
WSGI doesn't mandate any specific feature of generators, such as
coroutine-like semantics, and the server doesn't have to know about
them.
The joy of writing a new specification is that we are not (potentially)
shackled by old ways of doing
07.01.2011 07:24, Alex Grönholm kirjoitti:
07.01.2011 06:49, P.J. Eby kirjoitti:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Tossing the idea around all day long will then, of course, be
happening regardless. Unfortunately for that particular discussion,
PEP 3148 / Futures seems
07.01.2011 19:59, Guido van Rossum kirjoitti:
If it's optional, what's the benefit for the app of getting it through
WSGI instead of through importing some other standard module? The API
of the executor will require a lot of thought. I worry that this
weighs down the WSGI standard with the
Alice Bevan–McGregor al...@... writes:
On 2011-01-07 13:21:36 -0800, Antoine Pitrou said:
Ok, so, WSGI doesn't already involve generators. QED.
This can go around in circles; by allowing all forms of iterable, it
involves generators. Geneators are a type of iterable. QED right
back.
08.01.2011 05:36, Antoine Pitrou kirjoitti:
Alice Bevan–McGregoral...@... writes:
On 2011-01-07 13:21:36 -0800, Antoine Pitrou said:
Ok, so, WSGI doesn't already involve generators. QED.
This can go around in circles; by allowing all forms of iterable, it
involves generators. Geneators are
At 12:37 PM 1/7/2011 -0800, Alice BevanMcGregor wrote:
But is there really any problem with providing a unified method for
indication a suspend point?
Yes: a complexity burden that is paid by the many to serve the few --
or possibly non-existent.
I still haven't seen anything that suggests
At 01:22 PM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-07 08:28:15 -0800, P.J. Eby said:
At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome
byincorporatingthe most common (1%) of
08.01.2011 07:09, P.J. Eby kirjoitti:
At 12:37 PM 1/7/2011 -0800, Alice BevanMcGregor wrote:
But is there really any problem with providing a unified method for
indication a suspend point?
Yes: a complexity burden that is paid by the many to serve the few --
or possibly non-existent.
I
On 2011-01-07 20:34:09 -0800, P.J. Eby said:
That it [handling generators] is difficult at all means removes
degree-of-difficulty as a strong motivation to switch.
Agreed. I will be following up with a more concrete idea (including
p-code) to better describe what is currently in my brain.
On 2011-01-07 22:13:17 -0800, Alex Grönholm said:
08.01.2011 07:09, P.J. Eby wrote:
On the plus side, the run this in a future after the request concept
has some legs... [snip]
What exactly does run this in a future after the request mean? There
seems to be some terminology confusion here.
On 2011-01-07 13:21:36 -0800, Antoine Pitrou said:
Ok, so, WSGI doesn't already involve generators. QED.
Let me try this again. With the understanding that:
:: PEP 333[3] and 444 define a response body as an iterable.
:: Thus WSGI involves iterables through definition.
:: A generator is a
Alice Bevan–McGregor al...@... writes:
agronholm: what new features does pep 444 propose to add to pep ? \
async, filters, no buffering?
GothAlice: Async, filters, no server-level buffering, native string
usage, the definition of byte string as the format returned by
socket read
On Wed, 5 Jan 2011, Alice Bevan–McGregor wrote:
This should give a fairly comprehensive explanation of the rationale behind
some decisions in the rewrite; a version of these conversations (in narrative
style vs. discussion) will be added to the rewrite Real Soon Now™ under the
Rationale
At 01:03 PM 1/6/2011 +, chris.d...@gmail.com wrote:
Does that apply here? It seems you either allow unicode strings or you
don't, not a certain subsection.
That's why PEP requires bytes instead - only the application
knows what it's sending, and the server and middleware shouldn't
On 2011-01-06 03:53:14 -0800, Antoine Pitrou said:
Alice Bevan-McGregor al...@... writes:
GothAlice: ... native string usage, the definition of byte string as
the format returned by socket read (which, on Java, is unicode!) ...
Just so no-one feels the need to correct me; agronholm made
Chris,
On 2011-01-06 05:03:15 -0800, Chris Dent said:
On Wed, 5 Jan 2011, Alice Bevan–McGregor wrote:
This should give a fairly comprehensive explanation of the rationale
behind some decisions in the rewrite; a version of these
conversations (in narrative style vs. discussion) will be added
At Thu, 6 Jan 2011 13:03:15 + (GMT),
chris dent wrote:
snip
On async:
I agree with some others who have suggested that maybe async should be
its own thing, rather than integrated into a WSGI2. A server could
choose to be WSGI2 compliant or AWSGI compliant, or both.
/snip
+1
After
Hello web-sig. My name is Timothy Farrell. I'm the developer of the Rocket
web server. I understand that most of you are more experienced and passionate
than myself. But I'm come here because I want to see certain things
standardized. I'm pretty new to this forum but I've read through all
On 2011-01-06 09:06:10 -0800,
chris.d...@gmail.com said:
I wasn't actually talking about the log dump. That was useful. What I
was talking about were earlier messages in the thread where people were
making responses, quoting vast swaths of text for no clear reason.
Ah. :) I do make an
06.01.2011 20:02, Eric Larson kirjoitti:
At Thu, 6 Jan 2011 13:03:15 + (GMT),
chris dent wrote:
snip
On async:
I agree with some others who have suggested that maybe async should be
its own thing, rather than integrated into a WSGI2. A server could
choose to be WSGI2 compliant or AWSGI
On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote:
:: Making optional (and thus rarely-implemented) features non-optional. E.g.
server support for HTTP/1.1 with clarifications for interfacing applications
to 1.1 servers. Thus pipelining, chunked encoding, et. al. as per the HTTP
1.1
Alice Bevan–McGregor wrote:
chris.d...@gmail.com said:
I can't get my head around filters yet...
It isn't necessary; it is, however, an often re-implemented feature of
a framework on top of WSGI. CherryPy, Paste, Django, etc. all
implement some form of non-WSGI (or, hell, Paste uses WSGI
2011/1/6 Alex Grönholm alex.gronh...@nextday.fi
06.01.2011 20:02, Eric Larson kirjoitti:
At Thu, 6 Jan 2011 13:03:15 + (GMT),
chris dent wrote:
snip
On async:
I agree with some others who have suggested that maybe async should be
its own thing, rather than integrated into a WSGI2. A
On 2011-01-06 13:06:36 -0800, James Y Knight said:
On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote:
:: Making optional (and thus rarely-implemented) features non-optional.
E.g. server support for HTTP/1.1 with clarifications for interfacing
applications to 1.1 servers. Thus
On Jan 6, 2011, at 4:56 PM, Alice Bevan–McGregor wrote:
On 2011-01-06 13:06:36 -0800, James Y Knight said:
On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote:
:: Making optional (and thus rarely-implemented) features non-optional.
E.g. server support for HTTP/1.1 with clarifications
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1 features work in a
controllable way. This is because WSGI gateways/adapters aren't often
directly interfacing with the raw HTTP layer, but with FASTCGI, SCGI,
AJP, CGI etc. In this sort of situation you
06.01.2011 23:11, Sylvain Hellegouarch kirjoitti:
2011/1/6 Alex Grönholm alex.gronh...@nextday.fi
mailto:alex.gronh...@nextday.fi
06.01.2011 20:02, Eric Larson kirjoitti:
At Thu, 6 Jan 2011 13:03:15 + (GMT),
chris dent wrote:
snip
On async:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1 features work in a
controllable way. This is because WSGI gateways/adapters aren't often
directly interfacing with the raw HTTP layer, but with FASTCGI,
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1 features work in a
controllable way. This is because WSGI gateways/adapters aren't often
directly
2011/1/7 Graham Dumpleton graham.dumple...@gmail.com:
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1 features work in a
controllable way. This is
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
On Jan 6, 2011, at 7:46 PM, Alex Grönholm wrote:
The WebDAV spec, on the other hand, says
(http://www.webdav.org/specs/rfc2518.html#STATUS_102):
The 102 (Processing) status code is an interim response used to inform the
client that the server has accepted the complete request, but has
2011/1/7 James Y Knight f...@fuhm.net:
On Jan 6, 2011, at 7:46 PM, Alex Grönholm wrote:
The WebDAV spec, on the other hand, says
(http://www.webdav.org/specs/rfc2518.html#STATUS_102):
The 102 (Processing) status code is an interim response used to inform the
client that the server has
07.01.2011 04:55, Graham Dumpleton kirjoitti:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One
At 12:52 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Ignoring async for the moment, the goals of the PEP 444 rewrite are:
:: Clear separation of narrative from rules to be
followed. This allows developers of both servers and applications
to easily run through a confomance check list.
::
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Tossing the idea around all day long will then, of course, be
happening regardless. Unfortunately for that particular discussion,
PEP 3148 / Futures seems to have won out in the broader scope.
Do any established async frameworks or
On 2011-01-06 14:14:32 -0800, Alice Bevan–McGregor said:
There was something, somewhere I was reading related to WSGI about
requiring content-length... but no matter.
Right, I remember now: the HTTP 1.0 specification. (Honestly not
trying to sound sarcastic!) See:
07.01.2011 06:49, P.J. Eby kirjoitti:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Tossing the idea around all day long will then, of course, be
happening regardless. Unfortunately for that particular discussion,
PEP 3148 / Futures seems to have won out in the broader scope.
Do
On Jan 7, 2011, at 12:13 AM, Alice Bevan–McGregor wrote:
On 2011-01-06 14:14:32 -0800, Alice Bevan–McGregor said:
There was something, somewhere I was reading related to WSGI about requiring
content-length... but no matter.
Right, I remember now: the HTTP 1.0 specification. (Honestly not
On Thu, Jan 6, 2011 at 8:49 PM, P.J. Eby p...@telecommunity.com wrote:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Tossing the idea around all day long will then, of course, be happening
regardless. Unfortunately for that particular discussion, PEP 3148 /
Futures seems to have
On 2011-01-06 21:26:32 -0800, James Y Knight said:
You've misread that section. In HTTP/1.0, *requests* were required to
have a Content-Length if they had a body (HTTP 1.1 fixed that with
chunked request support). Responses have never had that restriction:
they have always (even since before
[Apologies if this is a double- or triple-post; I seem to be having a
stupid number of connectivity problems today.]
Howdy!
Apologies for the delay in responding, it’s been a hectic start to the
new year. :)
On 2011-01-03, at 6:22 AM, Timothy Farrell wrote:
You don't know me but I'm the
Alex Grönholm and I have been discussing async implementation details
(and other areas of PEP 444) for some time on IRC. Below is the
cleaned up log transcriptions with additional notes where needed.
Note: The logs are in mixed chronological order — discussion of one
topic is chronological,
At 05:04 PM 1/2/2011 +1100, Graham Dumpleton wrote:
That PEP was rejected in the end and was
replaced with PEP 342 which worked quite differently, yet I cant see
that the WSGI specification was revisited in light of how it ended up
being implemented and the implications of that.
Part of my
Alice and Graham,
I worry a lot that there's a fight brewing here that will lead to
disappointment all around. I see accusations, demands, and passion. I also
see a lot of apathy in the web-sig. This is not a recipe for a successful
standard.
Since it appears we have or are about to face a
On Sun, 2011-01-02 at 09:21 -0800, Guido van Rossum wrote:
Graham, I hope that you can stop being grumpy about the process that
is being followed and start using your passion to write up a critique
of the technical merits of Alice's draft. You don't have to attack the
whole draft at once --
On Sun, Jan 2, 2011 at 12:14 PM, Alice Bevan–McGregor
al...@gothcandy.comwrote:
On 2011-01-02 09:21:29 -0800, Guido van Rossum said:
Alice hasn't posted a link to her rewrite of PEP 444 in a while. AFAICT
it's this: https://github.com/GothAlice/wsgi2/blob/master/pep444.textile. I
find it a
On Sun, Jan 2, 2011 at 12:55 PM, Masklinn maskl...@masklinn.net wrote:
On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote:
On 2011-01-02 11:14:00 -0800, Chris McDonough said:
I'd suggest we just embrace it, adding minor tweaks as necessary, until
we reach some sort of technical impasse it
On 2011-01-02, at 23:16 , Alice Bevan–McGregor wrote:
(Just trying to keep this thread from degenerating into a shouting match.)
I missed how his statements could be construed as offensive. :/
I missed it as well (though my report might have been brusque), and definitely
didn't intent it to be
At 12:38 PM 1/2/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-02 11:14:00 -0800, Chris McDonough said:
I'd suggest we just embrace it, adding minor tweaks as necessary,
until we reach some sort of technical impasse it doesn't address.
Async is one area that does not cover, and that
At 02:21 PM 1/2/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-02 11:57:19 -0800, P.J. Eby said:
* -1 on the key-specific encoding schemes for the various CGI
variables' values -- for continuity of coding (not to mention
simplicity) PEP 's approach to environ encodings should beused.
Until the PEP is approved, it's just a suggestion. So for it to really be
WSGI 2 it will have to go through at least some approval process; which is
kind of ad hoc, but not so ad hoc as just to implicitly happen. For WSGI 2
to happen, someone has to write something up and propose it. Alice has
Howdy!
I've mostly finished a draft rewrite of PEP 444 (WSGI 2), incorporating
some additional ideas covering things like py2k/py3k interoperability
and switching from a more narrative style to a substantially
RFC-inspired language.
http://bit.ly/e7rtI6
I'm using Textile as my
On Sun, Dec 12, 2010 at 9:59 PM, Alice Bevan–McGregor
al...@gothcandy.comwrote:
Howdy!
There's one issue I've seen repeated a lot in working with WSGI1 and that
is the use of middleware to process incoming data, but not outgoing, and
vice-versa; middleware which filters the output in some
On Tue, Dec 14, 2010 at 12:54 PM, Alice Bevan–McGregor
al...@gothcandy.comwrote:
An application is an application and servers are imagined but not actually
concrete.
Could you elaborate? (Define concrete in this context.)
WSGI applications never directly touch the server. They are
Alice Bevan–McGregor
There's one issue I've seen repeated a lot in working with WSGI1 and
that is the use of middleware to process incoming data, but not
outgoing, and vice-versa; middleware which filters the output in some
way, but cares not about the input.
Wrapping middleware around an
That looks amazingly like the code for CherryPy Filters circa 2005. In
version 2 of CherryPy, Filters were the canonical extension method
(for the framework, not WSGI, but the same lessons apply). It was still
expensive in terms of stack allocation overhead, because you had to
call () each
Howdy!
There's one issue I've seen repeated a lot in working with WSGI1 and
that is the use of middleware to process incoming data, but not
outgoing, and vice-versa; middleware which filters the output in some
way, but cares not about the input.
Wrapping middleware around an application is
I’ve updated my copy of the PEP, re-naming non-commentary and non-revision text
to reference WSGI2, wsgi2, or wsgi (environment variables) as appropriate.
I’ve also added the first draft of the text describing filters and some sample
code, including a middleware adapter for filters. Here are
Ok. Retracted.
I have been admiring the purity and simplicity of the JSON spec which
intentionally has no version number. New changes are therefore only
allowed with a new name. That removes a lot of complexity around
figuring out what versions of the spec what server implements, etc.
But the
Would you prefer to give me collaboration permissions on your repo, or should I
fork it?
This message was sent from a mobile device. Please excuse any terseness and
spelling or grammatical errors. If additional information is indicated it will
be sent from a desktop computer as soon as
I’ve forked it, now available at:
https://github.com/GothAlice/wsgi2
Re-naming it to wsgi2 will be my first order of business during the week,
altering your association the second. I’ll post change descriptions for
discussion as I go.
— Alice.
On 2010-11-22, at 12:12 AM,
I would very much prefer it if we could keep the current name or
choose a new unrelated name, not wsgi2 as I think there API changes
warrant a new name to prevent confusion.
--Mark
On Mon, Nov 22, 2010 at 3:18 AM, Alice Bevan-McGregor
al...@gothcandy.com wrote:
I’ve forked it, now available at:
1 - 100 of 168 matches
Mail list logo
