At 08:11 PM 1/31/2006 -0600, Ian Bicking wrote: >Please, say what is wrong about the spec itself, not what is wrong about >the scope of the spec.
The first things that come to mind are: 1. It disadvantages better solutions (whether frameworks or templates) by reducing everything to the least common denominator 2. It doesn't give templates access to the request or response without creating new specifications for how they're to be encoded in vars -- which would end up recapitulating the pre-WSGI "common request/response" arguments all over again 3. Doesn't allow the framework to control the lifetime of compiled resources 4. Lack of relationship to HTTP makes it irrelevant/out-of-scope for Web-SIG; it should go to a string or text processing SIG. 5. Makes Web-SIG do-over a problem that TurboGears and Buffet have already solved. (That is, there's already a usable solution for what this does; it doesn't need *another* specification; let's use the current focus of attention to go after an actual opportunity to *improve*.) Problems 1-4 are simple to solve by having resources be WSGI application objects. The rest of the standardization could then be reduced to what additional environ keys should be supplied by frameworks. And then we could get to work on solving the resource deployment problem instead. Look-and-feel customizability of reusable web application components is an incredibly important problem, on a scale comparable to the problems that setuptools and eggs solve, and it's a much bigger issue for man-in-the-street use of Python as a web platform than WSGI itself is. My wife isn't a programmer, but she's hacked PHP applications to customize their look and feel. (Of course, these apps then aren't really upgradeable any more, because their code has effectively been branched.) A Python standard for resource location would allow us to have tools that run against a project and spit out a directory tree with just resources for you to edit, and to build eggs of your newly-customized UIs. If this is a *standard* for Python web apps, then it means you only learn it once. Sure, you'll have to learn the template syntax used by different apps or components, but that's not a big deal if you're mainly looking to change the HTML anyway. Also, it enables a market for third-party customizations: i.e., people creating skins for popular components/apps. If we can solve the resource deployment problem in a way that allows creating tools that people like my wife can use, we will have succeeded in moving the Python web platform forward significantly, in terms of what will be available to users, not just developers. _______________________________________________ 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
