On 13 October 2014 17:12, Benoit Chesneau <bchesn...@gmail.com> wrote: > ... > > > OK, > > So I should probably know you, but I can't recollect right now what you do > or write.
Its not clear to me who you were replying to. If Graham - Graham is the mod_wsgi maintainer, which I'm sure you've heard of - he, like you is one of the actors we need engaged and behind this effort. And PJE was the original WSGI maintainer :). > Anyway I find it really disturbing the way you're actually acting > and try to push your ideas based on private feedback coming from unknown or > choosing who should be a reference. That certainly not the right way to have > all actors on the table. Because if we go for a new WSGI spec, you certainly > want it. And I am speaking as one of these actors. As I said when folk talked about going private in the first thread on this, I'm willing to discuss anything publically or privately - I can't tell folk where they will be comfortable discussing things. But I'm going to do *my* work on this in public, because I think that is essential to get broad consensus. > In my opinion, if we want to go further we should first define what are the > problem we want to solve, and then get the feedback from all the actors > around: I think I've been fairly clear about the problem *I* want to solve. """ We want to create a clean common API for applications and middleware written in a post HTTP/2 world - where single servers may accept up to all three of HTTP/1.x, HTTP/2 and Websocket connections, and applications and middleware want to be able to take advantage of HTTP/2 and websockets when available, but also degrade gracefully. We also want to ensure that there is a graceful incremental path to adoption of the new API, including Python 2.7 support, and shims to enable existing WSGI apps/middleware/servers to respectively be contained, contain-or-be-contained and contain, things written to this new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality. """ > - framweorks authors I reached out to a number of such authors directly. I encourage you to do the same. > - libraries author Ditto and > - server authors Ditto :). > If you don't have all actors around and majors are missing, there is > probably no point to continue. I do think the idea of having a repository to > collect it with people arbitrating the discussions on them on the mailing is > a good way to go further. Now I think we are still missing of a clear > definition of the problem. This is from what we should start instead of > starting by giving our philosophy on how the problem should be solved. Here's my definition of some of the problems: A - there is no common spec equivalent to WSGI that permits writing server side code that takes advantage of HTTP/2. There's *a* http/2 server out there which one can write code for, but that code is either specific to that servers plumbing, or plain WSGI and misses the HTTP/2 goodness. B - WSGI has some oddness and overheads due in large part to the situation it was aiming to fix (which it broadly did) that perhaps we can now come together to fix. C - Support for chunked uploads, comet, bosh and websockets is effectively impossible within WSGI - one ends up writing server specific code, and being tied to a single server - even though multiple servers support (some of) those things. This defeats the point of WSGI IMNSHO: its not that WSGI is broken or anything, its just that we're once again writing all our generic middleware in server-specific fashions. Because the world has moved on and we haven't. I think A and C are crucial if we want to re-instate a lingua franca for the current web, in Python. I'd like to address B, because we can. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
