On 30 September 2014 08:41, Roberto De Ioris <robe...@unbit.it> wrote: > While i totally like your proposal, i fear it will not solve one of the > biggest problems without another layer: > > currently (and i speak as the uWSGI author, so i am the first guilty here) > when you want to use non-WSGI features you generally call into server api > (like the one exposed in the 'uwsgi' virtual module). This means each > server has its api, and this result as middlewares and apps to be adapted > to each one (if possible) > > My proposal is to push "mensa" but to standardize a series of api > (websockets and push at least) on top of it so that frameworks and > middlewares can use them without worrying about the lower stack.
This was exactly the concern I was about to articulate. Having a standard way to 'escape' WSGI is great, but what it does is force us down a road where any application that wants to use HTTP/2 or WebSockets picks one server at the start of its life and is effectively tied to that server. Any application small enough to be easily ported is also small enough that it isn't a reasonable test of the API. Any application large enough to really provide insight into the APIs is also large enough that it will rapidly become tightly coupled to its server implementation. Additionally, it's a cost for server authors (unless they think they really do have the ability to provide the 'best' API around which all of us will rally). Server authors are going to have enough work just making their servers speak HTTP/2 out the front, asking them to also invest work in designing an API that *might* get used by a small fraction of applications is really a big ask. Finally, the odds of us getting buy-in from frameworks is surely not very high. What interest will, for example, Armin Ronacher have in having support for uWSGI's specific HTTP/2 API in werkzeug/Flask? What about gunicorn's? Or mod_wsgi's? I appreciate the argument for wanting to let server+middleware authors develop the APIs themselves and then standardise around it, I really do. But without a concrete plan of who is going to make the first investment, I think it just leaves us sitting around doing nothing. A better approach would be to say, as Roberto suggested, "hey, here's this generic WSGI escape mechanism, and here are some generic HTTP/2 and Websocket APIs you can escape to". We could even version those APIs, allowing for communal development of them between server authors. That provides the initial escape hook and an initial direction, reducing the risk for individual server authors. _______________________________________________ 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
