On Sat, Sep 20, 2014 at 3:22 PM, Dirkjan Ochtman <dirk...@ochtman.nl> wrote:
> On Sat, Sep 20, 2014 at 9:23 AM, Robert Collins > <robe...@robertcollins.net> wrote: > > Well, thats certainly a challenge :). Whats the governance model here? > > Is a PEP appropriate, and if so - that gives us a BFDL or BFDL > > PEP-delegate to decide between bikeshed issues; and if its not a > > bikeshed issue then resolving it is actually necessary. > > Yes, I think a good way forward would be to have a small cabal write a > PEP and then announce it here for further feedback and then > pronouncement by a BDFL or -delegate. If you want to be lead/editor, > that sounds great. It also seems like you should definitely involve > Graham and give credence to his thoughts. > > I'd be excited about this and happy to give feedback a little later > once you've got some initial draft, as someone who likes to implement > his applications directly on top of WSGI for now (but I've also > implemented a couple of WebSocket servers). > > Cheers, > > Dirkjan > > Last time was more about everyone wanted to discuss about the changes with its own requirement list. Which is already conflicting. Discussing if it should be done outside the media designed for it is already out of topic imo. So I won't discuss about it further. Instead I wonder what is the appropriate medium to collect requirements and others stuffs about it. Wiki ? Anything else? For a start I see these different topics 1) HTTP 1.1 vs HTTP 2: - HTTP 1.1 and HTTP2 have quite the same high level syntax (methods, uri, headers, ...) but the way the data is transported differs. (data are sent by frames in HTTP 2). - in HTTP 2, data can be encrypted and compressed. - in HTTP2 data can pushed from the server to the clients. More data can be sent to the client - in HTTP2 streams are multiplexed We have the concept of data channels and these are more like message passings. Multiplexing existed in HTTP 1.1 with pipelines but is barely supported right now by WSGI servers. The concept of data channels and the PUSH features will requires more concurrency at the server level. At the application, things doesn't change that much. Everything can appear like before. The only change is the PUSH feature. 2) Websockets, SSE and other similar protocoles are completely asynchronous. All this part is not really handled by WSGI. The way it is generally implemented right now is awkward. The server generally extend the WSGI protocol so the application get the socket. Then a specific library handle the rest. I actually wonder if websockets or other asynchronous protocols should be handled by the new WSGI SPEC. Shouldn't we just standardize the way the socket is given to another library? Anyway I think we should collect all requirements at application and server level and then start to confront the current WSGI spec to them. And iterate. Thoughts? Any other topic? - benoit
_______________________________________________ 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