At 01:28 PM 2/5/2006 +0000, Alan Kennedy wrote: >I've been dismayed over the last few days trying to follow the direction >of this thread: it appears to me that something very simple has now >become very complex.
On the contrary, the situation is and always has been very complex. It only appears simple if you restrict your view to a particular narrow set of use cases and ignore everyone else's. Python web frameworks are extremely diverse in audience, needs, philosophies, and implementation. A "standard" that doesn't take this into consideration is divisive, when what we need to be doing is unifying. Having a standard that takes diversity into consideration may be slightly more complex, but it allows *consolidation* to occur over time. The *real* additional complexity here is communication. Since each framework has its own conceptual model of how things work, we've been spending a lot of time just learning to understand each other. While time consuming, it is absolutely a worthwhile effort if your goal is to get everybody closer together. If we only discuss what we already have in common, we are simply dividing the world into "us" and "them", preaching to the choir and getting nowhere new. That is why I've been fighting to hold off a mere rubber-stamping of a non-web standard that happens to work for one family of frameworks; it would be better for all of us if those use cases are handled as part of a spec that brings everybody closer together. That's not going to be as easy, true. It certainly hasn't been easy for the people discussing it so far (myself absolutely included), and it certainly won't be for the people reading the spec or implementing it. However, not everything that is worthwhile is easy. Developing WSGI was not easy, either, as I'm sure you recall. You and I certainly argued a bit about iterators and file-like objects and such, and it took a while before I understood all of your use cases and we were able to resolve them in the spec. If you had given up on convincing me then, or if I had given up on your use cases as "too complex", the spec would have suffered for it. (And you wouldn't have gotten that prominent credit in the PEP 333 "Acknowledgments" section. ;) ) >I can understand why the web-sig has fallen into the trap of tying a >tmeplating API to its nice web standard, WSGI: all web applications must >generate output. But web apps need to generate a wide range of media >types, e.g. image/*, application/msword, etc, etc, etc. And in many frameworks, it is the *template* that decides what media type it is generating - and it may not even be outputting text or unicode. Again, this is something that would be neglected by a text-only spec. >This topic started with Buffet, the de-facto standard templating API for >CherryPy. Buffet is just about textual templating, which is a good >thing. That's why it's very simple, and is thus actually being used. Which is precisely why we don't need to rush into blessing it as some kind of web standard, when it doesn't have anything to do with the "web", as far as I can tell. If I needed a plugin for pure text or XML templating (as opposed to *web application* templates), or I were creating a pure text or XML output generator, I would absolutely use the TG/Buffet API, no question. It is 100% the right tool for the job, and the de facto standard as well. But I'm also 100% positive that it is *not* suitable to be declared a Python *web* standard by itself: it's not about the web at all. The web just happens to be where it's being used at the moment, and only in frameworks where the use cases slot neatly together with it. Heck, just look at the API documentation and see if you can find the word "web" or even "request" mentioned on the page: http://www.turbogears.org/docs/plugins/template.html >I used that TAL implementation to generate the documentation for various >things, usually just a flat set of HTML files in a directory: not a HTTP >request in sight. Theoretically, I can envision a situation where I >might want to swap TAL implementations for that offline generation >process, meaning that it would be helpful to have a standardised API for >controlling template cooking. > >Why should I have to use WSGI in that scenario? You don't have to. As I mentioned many times in the discussion on subtemplating, nothing stops template objects from offering *additional* APIs besides WSGI. It's just that if we're making a *web* standard here, then it should be possible for templates to do *web* things, not just play with strings. Ergo, the string part of the API should be an optional extension, or a standard part of the API but allowed to throw exceptions if the template tries to do something that requires WSGI. In contrast, I've listed numerous scenarios and use cases where providing WSGI or something like it is absolutely essential. Nobody is proposing any alternatives that would be part of the standard, as opposed to non-standard conventions. I want to make sure that *your* use cases are supported by the spec. In the absolute worst case scenario, you might have to do a little wrapping to meet them. But I also want to support *my* use cases, and those of other frameworks with similar ones. Those cases can't be supported without a *web* API, which TG/Buffet does not provide. We're all having this conversation because we want to achieve consensus so we can achieve something in common, and use each other's tools. But we're not going to have consensus while people's use cases are being left out altogether. Nor will we have the greatest interoperability of tools if we exclude entire classes of frameworks and templates from playing. I believe that we can have a spec that allows for all the use cases being discussed. Certainly, it will not be as simple as the TG/Buffet API. However, if what you want is only the TG/Buffet API with some tweaks, then you are saying you do not want co-operation with at least Zope and Python server pages (which latter group includes at least users of Spyce, Webware, Snakecharmer, and mod_python, as far as I can tell). And that would seem to me to be a big enough subset of Python web users/developers to say you don't want a Python web standard at all. Why you'd want that, I'm not sure. Note that making it possible for people to run their existing code in *your* frameworks means that they have the option of migrating to your framework. But if you don't support that, they can't. It seems to me that it is in framework authors' best interest, then, to acknowledge the reality of these existing codebases and what will be required to let them migrate to another system. _______________________________________________ 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