[Web-SIG] WSGI - alternative ideas

[Phillip J. Eby]

At 10:13 AM 8/16/04 +0200, Paul Boddie wrote:

>The problem with (or rather the problem avoided by) WSGI is that it
>doesn't
>provide any coherency for people writing applications or higher-level
>frameworks - by the latter, I'm talking about things which do form
>handling
>and templating - you still have to choose your favourite framework and
>then
>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 [2].

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.