> On 21 Jan 2016, at 06:39, Benoit Chesneau <bchesn...@gmail.com> wrote: > > 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.
To clarify my own original message: when I described socket escape as ‘unworkable’, I expressly meant within the core WSGI specification as a mandatory feature. I remain interested in seeing a proposal for a formalised specification for it as a WSGI extension, and if you’d like help in writing that proposal I’m happy to lend a hand. Cory
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
