got an idea. What about having a page collecting feedback from anyone in the python community about this topic. So we can have true data from different perspectives: developer, library/framework author, server author. I'm OK to collect the data from it and make a summary of it once it's done.
The form it could take should be discussed first but imo that a good way to engage the community. What do you think? On Sat, Sep 20, 2014 at 4:17 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: > > > 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
