Ian Bicking
Posts: 900
Nickname: ianb
Registered: Apr, 2003
|
|
Re: Please Teach me Web Frameworks for Python!
|
Posted: Jan 27, 2006 2:54 PM
|
|
> In a sense, you can compare WSGI to XML; it's just a > serialization, which means there can be numerous API > implementations that manipulate it: DOMs, SAX, pull-DOMs, > ElementTree, etc. This means that over time, whatever > APIs the community considers "best" will dominate. WSGI > is there to support the evolution of *de facto* API > standards, not to create a "de jure" API standard.
I don't think de facto API standards will emerge magically via evolution. At some point a real standard (a useful standard of any kind) requires someone to step back and figure out what needs to be done to make it so. I think people assume somehow evolution will do that hard work all on its own. But developers aren't fruit flies, and live-or-die natural selection operates far too slow to be effective. People have been hoping this will just happen in Python web frameworks for years. But the withered older frameworks aren't dead yet, and the number of viable frameworks hasn't decreased.
For instance, an emerging standard is one developed in TurboGears and Buffet for calling templates. Imagine instead of the collaboration and combination of APIs that happened, that instead one of these frameworks (let's say TG) had just done what they needed to do to make template plugins for their framework and needs. They would have done something similar to what happened -- there'd be docs on how to write a plugin, and users who use and contribute plugins, and all the trappings of something ready to emerge as a standard. But then someone would come along and think "hey, I'll use their standard." And it would have kind of worked. They might have to mock out some parts of TG during the extraction process, and maintain those mock interfaces as TG developed. They'd have some problems, and they'd submit bug requests to the TG developers about the expectations in the interface and whatnot. And the TG developers would think, well sure that's nice, but that doesn't really matter to us, it works fine for us, and we have our own things we need to deal with. Everyone would eventually go their own ways, frustrated with the process.
This is why standards don't just emerge. Instead someone has to commit to making something appropriate for a standard -- well enough defined, applicable to a wide enough range of problems, distributed in a reasonable way. They can extract the standard from working code, but that is a conscious and willful act, and only the beginning of a standardization process.
I believe WSGI is a good basis for further standards. But Paul is right -- WSGI is not a complete web programming API. There is room for more standards, though I personally don't believe that those standards are best made on a framework API level (e.g., standards for a request object). There's lots of more interesting or useful standards that are within reach -- like that templating plugin standard. But they won't emerge without a push. (And even with a push it isn't inevitable -- I think, for instance, that WebStack is just trying to standardize the wrong thing at the wrong time)
Because standardization is hard, it works better when you don't take on too much at once. WSGI lets us approach some new areas piecemeal, without trying to birth a fully-formed standard. Sun can do what it wants because it owns its world. It's harder for us. But that's not all bad either.
|
|