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.
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? benoit On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > > On 21 Jan 2016, at 2:48 AM, Benoit Chesneau <bchesn...@gmail.com> wrote: > > > > On Wed, Jan 20, 2016 at 1:57 AM Robert Collins <robe...@robertcollins.net> > wrote: > >> On 20 January 2016 at 12:04, Benoit Chesneau <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 > > 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 > 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
