On Tuesday, October 14, 2014, Robert Collins <robe...@robertcollins.net> wrote:
On 14 October 2014 01:18, Benoit Chesneau <bchesn...@gmail.com> wrote: >> 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. > > > Chunkedn upload is possible and already handled with Gunicorn. But there is > no standard for that. Right. Thus we need one. > For C I would separate it from the rest. This a different discussion and imo > not everything can be achieved at the same time. Maybe we should start first > by fixing them, then go for the next step anyway. So the transition could be > incremental in servers and frameworks and actually fix the current spec. What makes C a different discussion? > > For A (And C), i think we should keep the new specification enough agnostic. > Especially since HTTP 2 is not yet completely out. HTTP/2 is in last call stage: it will be entirely finished by the time we get through whatever process we have here. What do you want to see changed in the process I'm following? -Rob I meant there are 2 separate problems: fixing the current spec, and extend it **if** needed to handle the new web patterns. I am speaking more about patterns than protocols. Protocol is one thing to take in consideration of course, but actually if we redefining a spec to build (server) and interact with (apps) a gateway for the web it will be more than simply handling HTTP 2 and soon HTTP 2.1 or 3 depending on the discussions. On the server started I started recently a redesign of the core of Gunicorn to prepare it tfor this pattern and beeing able to handle the different challengenns they gives. I actually identified some common features and distinct features. In term of patterns we have the following: - start a response: detect the protocol, eventually *upgrade* it to a new protocol (HTTP -> Websockets or HTTP2 -> HTTP 1.1) - send/receive headers - PUSH pattern: HTTP 2, new PUSH specifcations from W3C, SSE - ASYNC pattern: HTTP 2 and Websockets, receiving and sending can happen at different time and on the long term - Continuous connections: keepalive, HTTP 2 channels, websockets, SSE (how do we keep/identify connections states) - Streaams: chunked encoding, http 2 channels, ... We should have a clear way to notify the application about it. Also the spec/the server should have a standard way to handle the different async frameworks not based on threads like gevent, eventlet. The application should also be able to tell to the server that an operation will take a long time and let the server take appropriate actions. Some kind of reply/no_reply pattern allowing to answer later and switch to an async pattern on the fly if the server support it. It would allows the servers to handle more gracefully some common issues like long queries when the application knows about them. Since there is a concensus on using the github tracker, should i open a tickets for these different things? Or one generic? Let me know. - benoit -- 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
