headers
Ian Bicking | 3 Aug 2009 23:32
Gravatar

WSGI 2

So... what about WSGI 2?  Let's not completely drop the ball on this.
I *think* we were largely in agreement; debate got distracted by some
async stuff, but I don't think we particularly have to deal with that
for WSGI 2.  I think we do more than enough if we figure out: WSGI in
Python 3, i.e., with unicode; some basic errata kind of stuff, like
readline signature; change the callable signature to remove
start_response.

Would this be a new PEP or a revision?  I think it should be a new
PEP, as WSGI 1 remains valid and the same as it always was, and PEP
333 describes that.  Is there anyone willing to make the revisions?

--

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 13 comments |
headers
P.J. Eby | 4 Aug 2009 02:11
Gravatar

Re: WSGI 2

At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote:
>Would this be a new PEP or a revision?  I think it should be a new
>PEP, as WSGI 1 remains valid and the same as it always was, and PEP
>333 describes that.

+1 for a new PEP, since we'd be able to drop a lot of crufty examples 
and explanations about the cruddy bits.  wsgiref should add 1->2 and 
2->1 adapters.  (Although technically, running a WSGI 1 application 
in a WSGI 2 server requires either threads or greenlets.)

IMO, the main benefit of implementing WSGI 2 is to applications, not 
servers, with the possible exception of async servers (e.g. Twisted) 
that would prefer an iterator-only communications mode.  Such servers 
could refactor their WSGI 1 support into a (thread or greenlet-based) 
WSGI 2->1 adapter.

Synchronous servers, OTOH, might as well stay WSGI 1, and simply use 
a standard 1->2 adapter to support WSGI 2.

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 2 comments |
headers
Graham Dumpleton | 4 Aug 2009 02:38
Picon

Re: WSGI 2

2009/8/4 Ian Bicking <ianb@...>:
> So... what about WSGI 2?  Let's not completely drop the ball on this.
> I *think* we were largely in agreement; debate got distracted by some
> async stuff, but I don't think we particularly have to deal with that
> for WSGI 2.  I think we do more than enough if we figure out: WSGI in
> Python 3, i.e., with unicode; some basic errata kind of stuff, like
> readline signature; change the callable signature to remove
> start_response.
>
> Would this be a new PEP or a revision?  I think it should be a new
> PEP, as WSGI 1 remains valid and the same as it always was, and PEP
> 333 describes that.  Is there anyone willing to make the revisions?

But is the intention to skip straight to WSGI 2.0 for Python 3.0, with
start_response() being eliminated, or are we going to provide amended
WSGI 1.0 for Python 3.0? I can't see how we can avoid the latter and
so we should focus on that first rather that more fundamental changes
in WSGI 2.0.

In respect of WSGI 1.0 for Python 3.0, I have pretty well come to the
conclusion that where we were heading before on that in one area is
wrong. I was about to make changes to mod_wsgi in line with what I
believe should be done and just release it without consultation given
that I couldn't see any discussion reaching any conclusion about it
soon. Since you have sent this email I will try one last time to get a
resolution on WSGI 1.0 for Python 3.0. If can't get one, I guess the
choices are to release the change anyway and provide an incompatible
implementation to what others are guessing should be done, or just rip
all the code out and not support Python 3.0 at all. Either seem
entirely reasonable since there is no WSGI 1.0 specification for
(Continue reading)

Permalink | Reply | 12 comments |
headers
Graham Dumpleton | 4 Aug 2009 02:48
Picon

Re: WSGI 2

2009/8/4 P.J. Eby <pje@...>:
> At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote:
>>
>> Would this be a new PEP or a revision?  I think it should be a new
>> PEP, as WSGI 1 remains valid and the same as it always was, and PEP
>> 333 describes that.
>
> +1 for a new PEP, since we'd be able to drop a lot of crufty examples and
> explanations about the cruddy bits.  wsgiref should add 1->2 and 2->1
> adapters.  (Although technically, running a WSGI 1 application in a WSGI 2
> server requires either threads or greenlets.)
>
> IMO, the main benefit of implementing WSGI 2 is to applications, not
> servers, with the possible exception of async servers (e.g. Twisted) that
> would prefer an iterator-only communications mode.  Such servers could
> refactor their WSGI 1 support into a (thread or greenlet-based) WSGI 2->1
> adapter.
>
> Synchronous servers, OTOH, might as well stay WSGI 1, and simply use a
> standard 1->2 adapter to support WSGI 2.

Personally I don't believe we should be trying to support async
servers in the WSGI specification. Leave it simple and cater for the
predominant case rather than make it complicated just to support what
is going to be a minority deployment. It was async servers that got
the whole discussion derailed last time. Leave input stream as is now
as it is a known quantity and shown through actual use to work
acceptably. Changing to an input iterator in my mind introduces too
many unknowns around how input buffering is going to behave. In worst
case you could really screw up performance because of a trickle of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Ramm | 4 Aug 2009 03:22
Picon
Gravatar

Re: WSGI 2

> In summary, just seems more sane to have stuff in WSGI environment be
> dealt with as UTF-8.

This sounds good to me.   Rack, Jack, and even java servlets seem to
make this assumption without significant trouble, and if nearly all
existing web servers do it internally, that's seems like an even
better argument.

--Mark Ramm
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 1 comment |
headers
Mark Ramm | 4 Aug 2009 03:23
Picon
Gravatar

Re: WSGI 2

> Personally I don't believe we should be trying to support async
> servers in the WSGI specification. Leave it simple and cater for the
> predominant case rather than make it complicated just to support what
> is going to be a minority deployment. It was async servers that got
> the whole discussion derailed last time. Leave input stream as is now
> as it is a known quantity and shown through actual use to work
> acceptably. Changing to an input iterator in my mind introduces too
> many unknowns around how input buffering is going to behave. In worst
> case you could really screw up performance because of a trickle of
> input coming into an application where no way for an application to
> control block size of what is read.

Yea, someone at work suggested that we should read from the input in a
file like way, and include a little chained file implementation in
wsgi ref, or just point to it in the spec, so people can read the
first 1000 bytes off of the input, and then pass along what they read,
plus the rest of the file in a way that's transparent to the
underlying application.   Makes good sense to me, and I'm pretty sure
I can find Rick's ittertools.chain inspired chained file
implementation.

--Mark
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Graham Dumpleton | 4 Aug 2009 04:24
Picon

Re: WSGI 2

2009/8/4 Mark Ramm <mark.mchristensen@...>:
>> In summary, just seems more sane to have stuff in WSGI environment be
>> dealt with as UTF-8.
>
> This sounds good to me.   Rack, Jack, and even java servlets seem to
> make this assumption without significant trouble, and if nearly all
> existing web servers do it internally, that's seems like an even
> better argument.

What do they do for response side though? Do they have the
bytes/string distinct that we are talking about, with bytes expected
by string accepted but only in representable as latin-1?

Graham
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 0 comments |
headers
P.J. Eby | 4 Aug 2009 05:39
Gravatar

Re: WSGI 2

At 10:48 AM 8/4/2009 +1000, Graham Dumpleton wrote:
>2009/8/4 P.J. Eby <pje@...>:
> > At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote:
> >>
> >> Would this be a new PEP or a revision?  I think it should be a new
> >> PEP, as WSGI 1 remains valid and the same as it always was, and PEP
> >> 333 describes that.
> >
> > +1 for a new PEP, since we'd be able to drop a lot of crufty examples and
> > explanations about the cruddy bits.  wsgiref should add 1->2 and 2->1
> > adapters.  (Although technically, running a WSGI 1 application in a WSGI 2
> > server requires either threads or greenlets.)
> >
> > IMO, the main benefit of implementing WSGI 2 is to applications, not
> > servers, with the possible exception of async servers (e.g. Twisted) that
> > would prefer an iterator-only communications mode.  Such servers could
> > refactor their WSGI 1 support into a (thread or greenlet-based) WSGI 2->1
> > adapter.
> >
> > Synchronous servers, OTOH, might as well stay WSGI 1, and simply use a
> > standard 1->2 adapter to support WSGI 2.
>
>Personally I don't believe we should be trying to support async
>servers in the WSGI specification.

I'm not suggesting adding anything for async servers; I'm just saying 
that they will likely prefer to use WSGI 2 and use a 2->1 adapter to 
do WSGI 1 support, whereas synchronous servers will likely prefer the reverse.

The WSGI spec doesn't currently require streaming upload support, so
(Continue reading)

Permalink | Reply | 0 comments |
headers
P.J. Eby | 4 Aug 2009 06:00
Gravatar

Re: WSGI 2

At 10:38 AM 8/4/2009 +1000, Graham Dumpleton wrote:
>1. When running under Python 3, applications SHOULD produce bytes
>output, status line and headers.
>
>This is effectively what we had before. The only difference is that
>clarify that the 'status line' values should also be bytes. This
>wasn't noted before. I had already updated the proposed WSGI 1.0
>amendments page to mention this.

+1

>2. When running under Python 3, servers and gateways MUST accept
>strings for output, status line and headers. Such strings must be
>converted to bytes output using 'latin-1'. If string cannot be
>converted then is treated as an error.
>
>This is again what we had before except that mention 'status line' value.
>
>3. When running under Python 3, servers MUST provide wsgi.input as a
>binary (byte) input stream.
>
>No change here.
>
>4. When running under Python 3, servers MUST provide a text stream for
>wsgi.errors. In converting this to a byte stream for writing to a
>file, the default encoding would be applied.
>
>No real change here except to clarify that default encoding would
>apply. Use of default encoding though could be problematic if
>combining different WSGI components. This is because each WSGI
(Continue reading)

Permalink | Reply | 2 comments |
headers
Graham Dumpleton | 4 Aug 2009 06:28
Picon

Re: WSGI 2

2009/8/4 P.J. Eby <pje@...>:
>> 5. When running under Python 3, servers MUST provide CGI HTTP and
>> server variables as strings. Where such values are sourced from a byte
>> string, be that a Python byte string or C string, they should be
>> converted as 'UTF-8'. If a specific web server infrastructure is able
>> to support different encodings, then the WSGI adapter MAY provide a
>> way for a user of the WSGI adapter to customise on a global basis, or
>> on a per value basis what encoding is used, but this is entirely
>> optional. Note that there is no requirement to deal with RFC 2047.
>>
>> This is where I am going to diverge from what has been discussed before.
>>
>> The reason I am going to pass as UTF-8 and not latin-1 is that it
>> looks like Apache effectively only supports use of UTF-8. Since this
>> means that mod_wsgi, and Apache modules for FASTCGI, SCGI, AJP and
>> even CGI likely cannot handle anything besides UTF-8 then I really
>> can't see the point of trying to cater for a theoretical possibility
>> that some HTTP client could use something besides UTF-8. In other
>> words, the predominant case will be UTF-8, so let us target that.
>>
>> So, rather than burden every WSGI application with the need to convert
>> from latin-1 back to bytes and then to UTF-8, let the server deal with
>> it, with server using sensible default, and where server
>> infrastructure can handle a different encoding, then it can provide
>> option to use that encoding and WSGI application doesn't need to
>> change.
>
> Maybe I'm missing something here, but what if Apache receives something
> encoded in Latin-1?  AFAIR, form POST encoding is determined by the encoding
> of the page containing the form; that's of course something that only
(Continue reading)

Permalink | Reply | 1 comment |

Gmane