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.dumple...@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 <bchesn...@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.dumple...@gmail.com> > wrote: > >> 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> 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
