> On 21 Jan 2016, at 9:27 AM, Benoit Chesneau <bchesn...@gmail.com> wrote: > > again. any server can do such implementation if we create a new Resource > abstraction. This abstraction would expose a common api to read and write. > The implementation would be specific to the server.
If you mean not exposing the raw socket and having a separate high level API for implementing something like WebSocket this was already talked about. The suggestion was that it should not be a part of WSGI. Develop that API independently with no link to WSGI. The idea of upgrading from WSGI to a different API isn’t practical for various WSGI servers as it isn’t possible to unwind the state of the connection path created to get to point of handling the WSGI application. The better scenario is that the switch to an alternate WebSocket API is handled completely within the web server however it needs to handle it, when it needs to handle it, and not be reliant on going into a WSGI application which then says, oh, I actually need that to be WebSocket. > Now like we have wsgi.thread I would instead suggest to add a system of > capability or extension like in smtp, imap, ... so the servers that > implement a specific extension can legally published it. Would it work for > you? Since there is nothing in WSGI environ called wsgi.thread now I have no idea what you are really suggesting here. Graham > benoit > > On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton <graham.dumple...@gmail.com > <mailto:graham.dumple...@gmail.com>> wrote: > >> On 21 Jan 2016, at 2:48 AM, Benoit Chesneau <bchesn...@gmail.com >> <mailto:bchesn...@gmail.com>> wrote: >> >> >> >> On Wed, Jan 20, 2016 at 1:57 AM Robert Collins <robe...@robertcollins.net >> <mailto:robe...@robertcollins.net>> wrote: >> On 20 January 2016 at 12:04, Benoit Chesneau <bchesn...@gmail.com >> <mailto:bchesn...@gmail.com>> wrote: >> >> > >> > not at all. But I made the assumption that the wsgi server maintained a >> > thread directly or not where the python application is running . >> > >> > In any case there is some sort of wrapping done in the same thread/process >> > where the python application is running. And then nothing stop to give the >> > socket away to the application and tell to the server to stop to >> > communicate >> > with it. >> >> What socket? >> >> Data could be being passed by shm, for instance. >> >> -Rob >> >> >> While shared memory would be quite a bad idea, then why not. I still don't >> see why having a way to upgrade the connection can't be done. >> >> Call it I/O resource or Socket, the issue is the same. At the end nothing >> stop the server to pass the control to the app. If we forget the socket >> (which is btw the simplest design) then the server could stop to control the >> I/O resource when the application ask it to do it. At some point either a >> garbage collection or a basic resource return/claim flow could be used to >> definitely free the resource. >> >> The thing behind that is that it would allow the WSGI spec to only focus on >> providing a strict gateway workflow without forcing the application to adopt >> a concurrency model aync or not. > > No one has said you cannot do it. because though it is only able to be > implemented in a subset of WSGI servers/adapters, then it doesn’t seem > appropriate that it be a part of the core WSGI specification. > > This is the role of a WSGI extension as found at: > > http://wsgi.readthedocs.org/en/latest/specifications.html > <http://wsgi.readthedocs.org/en/latest/specifications.html> > > So go talk to the authors of uWSGI, and the other couple of packages > available for trying to plug these into some of the pure Python based WSGI > servers and come to an agreement between yourselves as to a standard way of > doing it and the extension specification can be added to the wsgi.org > <http://wsgi.org/> site. > > Graham >
_______________________________________________ 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
