OK Phillip. Time for you to put your money on the line. Give us an interface so WE can shoot YOUR great ideas down for a change :)
~ Daniel Phillip J. Eby wrote: > 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