[Web-SIG] Collating follow-up on the future of WSGI

[Benoit Chesneau]

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.dumpleton at gmail.com>
wrote:

>
> On 21 Jan 2016, at 2:48 AM, Benoit Chesneau <bchesneau at gmail.com> wrote:
>
>
>
> On Wed, Jan 20, 2016 at 1:57 AM Robert Collins <robertc at robertcollins.net>
> wrote:
>
>> On 20 January 2016 at 12:04, Benoit Chesneau <bchesneau at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160120/78f97972/attachment.html>