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

[Benoit Chesneau]

because i am not speaking about making a specification, but a way to expose
in the API (environ) custom extensions that a server want to experiment.
there are actually no easy way except checking "wsgi." indeed but that
doesn't make it as clear as a separate namespace where to put all server
extensions could be. Like capability field is in imap world.

Also I am not trying to force anything, I want to discuss about a possible
update of the wsgi spec which I thought was this thread about. What I just
want to discuss is the *current* usage of some extensions that have been
rapidly dismissed as unworkable. Like I said I will come with a more formal
specification about them but I wanted to discuss first about and collect
counter arguments which are good too.

- benoît


On Thu, 21 Jan 2016 at 07:24, Graham Dumpleton <graham.dumpleton at gmail.com>
wrote:

> I am still confused as to why you keep talking as if you seemingly are
> trying to force extensions to the existing WSGI specification into the core
> WSGI specification when an alternative has already been cited.
>
> Extensions and the process for describing them and getting them accepted,
> plus the appropriate WSGI environ prefix, as has been mentioned before, is
> what is covered by:
>
>     http://wsgi.readthedocs.org/en/latest/specifications.html
>
> Being an extension means it is entirely optional for a WSGI server to try
> and implement it, thus allowing WSGI servers/adapters that cannot implement
> something to skip them. They stand as separate documents and would never
> become part of the core WGSI PEP.
>
> Is there an issue with doing extensions per the process, and in the WSGI
> environ namespace, that was outlined in that URL? You seem to be suggesting
> a completely new way of handling extensions and ignoring what was laid down
> before.
>
> So no one is saying you can’t have extensions, and that separate process
> gives you all the scope you need to do it.
>
> In drafting your specification just fit it reference to what is described
> in that URL, using ‘x-wsgiorg.’ prefix keys.
>
> Graham
>
>
> On 21 Jan 2016, at 4:13 PM, Benoit Chesneau <bchesneau at gmail.com> wrote:
>
> I am not speaking about websockets. You could use it for SSE, or some apps
> could use the Upgrade header to upgrade from http to their own protocol
> etc... The only discussion i saw about websockets are about the addition of
> an async api or an external api. I am not describing that. I am speaking
> about providing a low level abstraction like wsgi.input but adding to it
> the support of output. (I was referring to wsgi.multithread...). This low
> level interface would allow anyone to provide its own
> implementation(server) or usage (application) still acting as a *gateway* .
>
> Also who are "we"? I am starting to think the discussion is already done
> and only obscure details like the content_length or headers encoding should
> be discussed. The RAW_SOCKET have been added on demand of the gunicorn
> users. Such thing also exist in things like cherrypy if I remember. A lot
> of code around have been created over it. So before deciding it's
> unworkable or whatever I strongly invite you to consider it as an addition
> to the environ. And since some servers need to pass the data differently I
> then suggest a Resource object on which you can read and write and
> eventually poll. This is not a websocket but more a proxy ressource to the
> client connexion. I will come back asap with a small spec.
>
> I also propose a second addition to the protocol that formalize the
> addition of extensions to the protocol by the servers if they want to.
> Having for example something like "`wsg.extensions` . Such addition would
> help anyone to experiment changes over the wsgi before making such changes
> in the specification by itself possibly.
>
> I think we have a good opportunity to extend the WSGI specification to
> allow the users to take over the new challenges on the web without forcing
> them to use a concurrency mode or skip completely the WSGI spec. The
> interest I see in WSGI is its simplicity and low level interface allowing
> users to build whatever they want over it. The different workers and their
> support of different concurrency models and framework in gunicorn let me
> think it is possible. Are the participants of this thread ready to discuss
> it?
>
> - benoît
>
> On Wed, 20 Jan 2016 at 23:37, Graham Dumpleton <graham.dumpleton at gmail.com>
> wrote:
>
>> On 21 Jan 2016, at 9:27 AM, Benoit Chesneau <bchesneau at 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.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/20160121/55bc80b4/attachment.html>