On 2011-01-06 09:20:48 -0800, Randy Syring said:
Being a web application developer and relying on frameworks like
Werkzeug and WebOb, I may not have much of a dog in this fight.
All input is welcome; I do want to hear from both framework developers
and users of frameworks. I suspect this discussion ocurring on the
Web-SIG list would be somewhat of an impediment for users to
contribute, so thank you for posting!
However, I have been following web-sig for a couple years and I have
seen the difficulties involved in reaching consensus on
modifying/updating the WSGI spec.
I've read through the archives and seen the issues as well. I do
believe that, on this one topic, it will be simply impossible to please
everyone. Up here in Canada we have
Its clear to me that most people on this list who can contribute in
meaningful ways to the creation of WSGI 2 have very little time to do
so.
One benefit of mailing lists over other communications channels (IRC,
etc.) is that mailing list traffic sticks around for a while and
doesn't require realtime effort.
Motivation seems generally low anyway, because what we have currently works.
The burst of traffic after Guido offered to push PEP 3333 ratification
proves that what we have /doesn't/ currently work, at least, for
everyone. Python 3 continues to be a problem.
It may have warts, but it works, and that very fact seems to limit the
number of people interested in donating time to improving the spec.
Limiting the scope to Python 2; PEP 333 has a number of issues
including, I feel the worst sins for a "standard": ambiguity and
complexity. While people may feel comfortable with the standard they
have learned thus far, I don't think they should be complacent when it
comes to examining possible improvements.
Every time something controversial is added to the spec, its going to
make it that much harder to move forward.
Thus my pushing for the controversial parts to be optional. While,
demonstrably, not everyone will use these parts, having them be present
is important to capture mind-space and get people thinking about the
broader implications of what they code.
On 2011-01-06 05:03:15 -0800, Chris Dent said:
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.
Adding async to the spec is a death blow IMO. You gain nothing by
putting it in and lose a lot of interest and time spent discussing it.
Make it a separate PEP that references the first. That way, those who
don't really care about it can still work on WSGI 2 without the
distraction of the async parts. If you make the new async PEP
dependent on the WSGI 2 spec, then those ideas can be tossed around all
day long without distracting from or taking energy away from the core
WSGI 2 ideas.
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. Having a ratified
and incorporated language PEP (core in 3.2 w/ compatibility package for
2.5 or 2.6+ support) reduces the scope of async discussion down to:
"how do we integrate futures into WSGI 2" instead of "how do we define
an async API at all".
I suggest reviewing the Web-SIG history of previous async discussions;
there's a lot more to having a meaningful API spec than having a
plausible approach. It's not that there haven't been past proposals,
they just couldn't get as far as making it possible to write a
non-trivial async application that would actually be portable among
Python-supporting asynchronous web servers.
See my previous paragraph about futures.
[snip]
We only see what you write here, the burden of proof is on you to
communicate your attentions and agenda.
Unfortunately the reality is that no solution will be agreeable to
everyone, and, for lack of a better phrase, no amount of hand-holding
can make it otherwise.
I am attempting to improve my PR somewhat through the many posts today
and with as much thorough information as possible. ;)
Then again, my opinion and impression could be completely off, and if
that is the case, feel free to ignore me. :)
That, despite popular opinion otherwise, is something I rarely do,
though my brain is so full these days that some things might get
accidentally expunged from my LRU heap. ;)
- Alice.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
