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

[Cory Benfield]

> On 21 Jan 2016, at 06:39, Benoit Chesneau <bchesneau at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160121/936e8180/attachment-0001.sig>