[Web-SIG] PEP 444 / WSGI 2 Async

[chris.dent at gmail.com]

On Wed, 5 Jan 2011, Alice Bevan–McGregor wrote:

> This should give a fairly comprehensive explanation of the rationale behind 
> some decisions in the rewrite; a version of these conversations (in narrative 
> style vs. discussion) will be added to the rewrite Real Soon Now™ under the 
> Rationale section.

Thanks for this. I've been trying to follow along with this
conversation as an interested WSGI app developer and admit that much
of the thrust of things is getting lost in the details and people's
tendency to overquote.

One thing that would be useful is if, when you post, Alice, you could
give the URL of whatever and wherever your current draft is.

That out of the way some comments:

For me WSGI is a programmers' aid used to encourage ecapsulation and
separation of concerns in web applications I develop. After that there's
a bit about reuability and portability, but the structure of the
apps/middleware themselves are the most important concerns for me. I
don't use frameworks, or webob or any of that stuff. I just cook up
callables that take environ and start_response. I don't want my
awareness of the basics of HTTP abstracted away, because I want to make
sure that my apps behave well.

Plain WSGI is a good thing, for me, because it means that my
applications are a) very webby (in the stateless HTTP sense) and b)
very testable.

This is all works because WSGI is very simple, so my tendency is to be
resistant to ideas which appear to add complexity.

> --- 444 vs. 3333
> GothAlice: Async, filters, no server-level buffering, native string usage, 
> the definition of "byte string" as "the format returned by socket read" 
> (which, on Java, is unicode!), and the allowance for returned data to be 
> Latin1 Unicode. \ All of this together will allow a '''def hello(environ): 
> return "200 OK", [], ["Hello world!"]''' example application to work across 
> Python versions without modification (or use of b"" prefix)

On async:

I agree with some others who have suggested that maybe async should be
its own thing, rather than integrated into a WSGI2. A server could
choose to be WSGI2 compliant or AWSGI compliant, or both.

Having spent some time messing about with node.js recently, I can say
that the coding style for happy little async apps is great fun, but
actually not what I really want to be doing in my run-of-the-mill as-
RESTful-as-possible web apps.

This might make me a bit of a dinosaur. Or a grape.

That said I can understand why an app author might like to be able to
read or write in an async way, and being able to shelf an app to wait
around for the next cycle would be a good thing. I just don't want
efforts to make that possible to make writing a boring wsgi thing more
annoying.

On filters:

I can't get my head around filters yet. They sound like a different
way to do middleware, with a justification of something along the
lines of "I don't like middleware for filtering". I'd like to be
(directly) pointed at a more robust justification. I suspect you have
already pointed at such a thing, but it is lost in the sands of
time...

Filters seem like something that could be added via a standardized piece
of middleware, rather than being part of the spec. I like minimal specs.

> GothAlice: Latin1 = \u0000 → \u00FF — it's one of the only formats that can 
> be decoded while preserving raw bytes, and if another encoding is needed, 
> transcode safely. \ Effectively requiring Latin1 for unicode output ensures 
> single byte conformance on the data. \ If an application needs to return 
> UTF-8, for example, it can return an encoded UTF-8 bytestream, which will be 
> passed right through,

There's a rule of thumb about constraints. If you must constrain, do
none, one or all, never some. Ah, here it is:
http://en.wikipedia.org/wiki/Zero_One_Infinity

Does that apply here? It seems you either allow unicode strings or you
don't, not a certain subsection.

My own personal method is: textual apps _always_ return unicode
producing iterators and a piece of (required, thus not offical by some
people's biases) middleware turns it into UTF-8 on the way out. I've
naively never understood why you want do anything else? My general
rule is unicode inside, UTF-8 at the boundaries.

That's all I got so far. I applaud you for taking on this challenge.
It's work that needs to be done. I hope to be able to comment more and
make a close reading of the various documents, but time is tough
sometimes. I'll do what I can as I can.

Thanks.
-- 
Chris Dent                                   http://burningchrome.com/
                                  [...]