[Web-SIG] WSGI - alternative ideas
Phillip J. Eby
pje at telecommunity.com
Mon Aug 16 17:30:32 CEST 2004
At 10:13 AM 8/16/04 +0200, Paul Boddie wrote:
>The problem with (or rather the problem avoided by) WSGI is that it
>provide any coherency for people writing applications or higher-level
>frameworks - by the latter, I'm talking about things which do form
>and templating - you still have to choose your favourite framework and
>hope that the tricks you've employed will work on WSGI. This means that
>newcomers still have to stare down that recently pruned list on the
>WebProgramming page .
Well, at least it doesn't *add* a new choice to that list. ;)
It *does*, however, create an environment that allows for "non-framework"
frameworks, since middleware components can add arbitrary data and service
objects to the 'environ'. (And, there's also nothing stopping components
from being distributed as non-middleware functions or objects that one
supplies the 'environ' to, in order to obtain data or do things.)
So, even though WSGI itself doesn't provide a higher-level API, its
existence and popularity should eventually allow users to choose framework
services on a piece-by-piece rather than framework-at-a-time basis.
But, we won't get there if WSGI doesn't get implemented in web servers, and
it won't be attractive for server authors unless there's a "market" for
WSGI web servers. And there won't be a significant market for them unless
existing software, under existing frameworks, can run on WSGI.
Anyway, once WSGI middleware components are popular, there's then a market
for framework authors to allow WSGI components to be plugged in *below*
their frameworks, e.g. as objects in a Zope "folder", as Webware
"resources", etc. Once this happens, I expect some framework authors may
see the value in refactoring their framework as a collection of WSGI
middleware components... at which point frameworks disappear, and
components reign supreme. Ultimate choice and flexibility now belongs to
the user, and we all live happily ever after in the land of happy happy web
programmers, or something like that.
That is a *long* way off, however. The reality today is that nothing is
going to change without a clear win for the framework authors whose
frameworks own the bulk of the market share in Python web
applications. Trying to directly create a new, competing API is quite
simply an attack on their investment, and it's not going to get us
anywhere. At the least, such a new API doesn't do anything positive for
them. In principle, WSGI will let their apps run on more servers, and is
simple enough for server and framework authors to try it out as an experiment.
More information about the Web-SIG