Chris,
On 2011-01-06 05:03:15 -0800, Chris Dent said:
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.
Yeah; I knew the IRC log dump was only so useful. It's a lot of
material to go through, and much of it was discussed at strange hours
with little sleep. ;)
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.
Tomorrow (ack, today!) I'll finish converting over the PEP from Textile
to ReStructuredText and get it re-submitted to the Python website.
https://github.com/GothAlice/wsgi2/blob/master/pep444.textile
http://www.python.org/dev/peps/pep-0444/
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.
Kudos! That approach is heavily frowned upon in the #python IRC
channel, but I fully agree that working solutions can be reasonably
made using that methedology. There are some details that are made
easier by frameworks, though. Testing benefits from MVC: you can test
the dict return value of the controller, the templates, and the model
all separately.
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.
c) And very portable. You need not depend on some pre-arranged stack
(including web server).
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.
-1
That is already the case with filters, and will be when I ratify the
async idea (after further discussion here). My current thought process
is that async will be optional for server implementors and will be
easily detectable by applications and middleware and have zero impact
on middleware/applications if disabled (by configuration) or missing.
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.
Using futures, async covers any callable at all; you can queue up a
dozen DB calls at the top of your application, then (within a body
generator) yield those futures to be paused pending the data. That
would, as an example, allow complex pages to be generated and streamed
to the end-user in a efficient way -- the user would see a page begin
to appear, and the browser downloading static resources, while
intensive tasks complete.
I just don't want efforts to make that possible to make writing a
boring wsgi thing more
annoying.
+9001
See above.
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 offer several benefits, some of which are mild:
:: Simplified application / middleware debugging via smaller stack.
:: Clearly defined tasks; ingress = altering the environ / input,
egress = altering the output.
:: Egress filters are not executed if an unhandled exception is raised.
The latter point is important; you do not want badly written middleware
to absorb exceptions that should bubble, etc. (I'll need to elaborate
on this and add a few more points when I get some sleep.)
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.
Filters are optional, and an example is/will be provided for utilizing
ingress/egress filter stacks as middleware.
The problem with /not/ including the filtering API (which, by itself is
stupidly simple and would barely warrant its own PEP, IMHO) is that a
separate standard would not be seen and taken into consideration when
developers are writing what they will think /must/ be middleware.
Seing as a middleware version of a filter is trivial to create (just
execute the filter in a thin middleware wrapper), it should be a
consideration up front.
Latin1 = \u0000 → \u00FF [snip]
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.
+1
See my post from a few minutes ago which covers this.
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.
Thank you, and I look forward to additional input!
- Alice.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
