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

2016-01-20 Thread Benoit Chesneau
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

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

2016-01-20 Thread Graham Dumpleton
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

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

2016-01-20 Thread Benoit Chesneau
-- Forwarded message - From: Benoit Chesneau Date: Thu, 21 Jan 2016 at 06:12 Subject: Re: [Web-SIG] Collating follow-up on the future of WSGI To: Graham Dumpleton I am not speaking about websockets. You could use it for SSE, or

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

2016-01-20 Thread 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

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

2016-01-20 Thread Benoit Chesneau
On Wed, Jan 20, 2016 at 1:57 AM Robert Collins wrote: > On 20 January 2016 at 12:04, Benoit Chesneau wrote: > > > > > not at all. But I made the assumption that the wsgi server maintained a > > thread directly or not where the python application

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

2016-01-20 Thread Graham Dumpleton
> On 21 Jan 2016, at 2:48 AM, Benoit Chesneau wrote: > > > > On Wed, Jan 20, 2016 at 1:57 AM Robert Collins > wrote: > On 20 January 2016 at 12:04, Benoit Chesneau

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

2016-01-20 Thread Robert Collins
On 21 January 2016 at 11:27, Benoit Chesneau 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. > > Now like we

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

2016-01-20 Thread Benoit Chesneau
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. Now like we have wsgi.thread I would instead suggest to add a system of capability or extension

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

2016-01-20 Thread Graham Dumpleton
> On 21 Jan 2016, at 9:27 AM, Benoit Chesneau 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

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

2016-01-20 Thread Cory Benfield
> On 20 Jan 2016, at 06:04, Graham Dumpleton wrote: > > For response content, if a WSGI application currently doesn’t set a > Content-Length on response, A HTTP/1.1 web server is at liberty to chunk the > response. > > So I am not sure what is missing. My

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

2016-01-20 Thread André Malo
* Cory Benfield wrote: > > On 20 Jan 2016, at 06:04, Graham Dumpleton > > wrote: > > > > For response content, if a WSGI application currently doesn’t set a > > Content-Length on response, A HTTP/1.1 web server is at liberty to chunk > > the response. > > > > So I am

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

2016-01-20 Thread Graham Dumpleton
> On 20 Jan 2016, at 10:25 PM, André Malo wrote: > > * Cory Benfield wrote: > >>> On 20 Jan 2016, at 06:04, Graham Dumpleton >>> wrote: >>> >>> For response content, if a WSGI application currently doesn’t set a >>> Content-Length on response, A

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

2016-01-20 Thread André Malo
* Graham Dumpleton wrote: > > On 20 Jan 2016, at 10:25 PM, André Malo wrote: > > Regarding chunked requests - in my own WSGI implementation I went the > > most pragmatic way and simply provided a CONTENT_LENGTH of -1 for unknown > > request sizes (it maps very well to