> 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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to