[Web-SIG] PEP 444 / WSGI 2 Async

[Randy Syring]

Alice,

Being a web application developer and relying on frameworks like 
Werkzeug and WebOb, I may not have much of a dog in this fight.  
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.  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.  Jobs, family, and life in general 
limit the amount of time that can be spent on something like this.  
Motivation seems generally low anyway, because what we have currently 
works.  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.

So, getting a WSGI 2 spec discussed and approved is going to be hard 
enough.  Every time something controversial is added to the spec, its 
going to make it that much harder to move forward.  I'm not saying that 
means all controversial items should be dropped, some things are worth 
fighting for, just pointing out that IMO we are already working uphill, 
and adding weights to our rucksacks should only be done when absolutely 
necessary.

On 01/06/2011 10:44 AM, Alice Bevan–McGregor wrote:
>
> 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.

So, I agree with Chris and others who have said async should be a 
separate PEP.

-1 on having async in PEP 444 / WSGI 2

With respect to filters:

On 12/14/2010 04:25 PM, Ian Bicking wrote:
> <...>
> GzipFilter is wonky at best (it interacts oddly with range requests 
> and etags).  Prefix handling is useful (e.g., 
> paste.deploy.config.PrefixMiddleware), and usually global and 
> unconfigured.  Debugging and logging stuff often needs per-path 
> configuration, which can mean multiple instances applied after 
> dispatch.  Encoding and Decoding don't apply to WSGI.  Tidy is 
> intrusive and I think questionable on a global level.  I don't think 
> the use cases are there.  Tightly bound pre-filters and post-filters 
> are particularly problematic.  This all seems like a lot of work to 
> avoid a few stack frames in a traceback.
>

I agree with Ian's analysis of filters.  I don't see the benefit and its 
just another item to detract from other core issues that could be 
addressed.  -1 on filters.

Alice, I do appreciate the time you are giving this issue.  But my 
feeling so far is that the things you have focused on are not the things 
that concern most of the people pushing towards a WSGI 2.  On January 
2nd, Phillip Eby sent three emails to web-sig.  IMO, they had great 
wisdom concerning different parts of WSGI 2, async, and the political 
aspects of the PEP process.  Your approach so far doesn't seem to have 
benefited from that wisdom, especially regarding the latter two items, 
and IMO this ship is dead in the water until that changes.

What I mean is, your approach just doesn't seem to take the history of 
the web-sig and the main contributor's opinions into account enough.  I 
have been on the web-sig long enough to have respect for the opinions of 
guys like Ian, Graham, Phillip, Armin, etc.  They have shown their 
competence and their care through their contributions via code and via 
posts to this list.  I have personally benefited greatly by being able 
to use the code they have built and I trust them and their opinions with 
regards to issues discussed on web-sig.  So when I see Ian write the 
above about filters or I see Phillip write the following about async:

> 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. 
and I don't see you respond to their concerns/suggestions, it makes it 
difficult for me to trust the direction you are heading.

Overall, you have shown energy and a willingness to contribute, which I 
greatly appreciate.  But, I have the opinion that you are coming into 
this process ignorant of or mostly disregarding the many discussions 
that have taken place before on this list, are pushing an agenda that 
seems mostly defined by your likes and dislikes, and are mostly 
disregarding the suggestions/concerns of the list "heavy-weights".  That 
opinion may not be true, in fact, *I am not* even saying that is what is 
going on.  What I am saying is that this is what it *appears* like to a 
no-name follower of the web-sig.  We only see what you write here, the 
burden of proof is on you to communicate your attentions and agenda.  
That may not be fair, but if life were to suddenly get fair, I doubt it 
would happen on web-sig... :)

Then again, my opinion and impression could be completely off, and if 
that is the case, feel free to ignore me.  :)

--------------------------------------
Randy Syring
Intelicom
Direct: 502-276-0459
Office: 502-212-9913

For the wages of sin is death, but the
free gift of God is eternal life in
Christ Jesus our Lord (Rom 6:23)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20110106/02a09e73/attachment.html>