[Web-SIG] Regarding the WSGI draft

[Phillip J. Eby]

At 07:30 PM 8/26/04 +0100, Ben Sizer wrote:
>I just worry that it diverts attention from what I consider to be the real 
>issue facing Python on the web, which is making life easier for web 
>application developers, not framework developers.

Unfortunately, every effort to date to create a "framework to end all 
frameworks" has simply resulted in the existence of framework 
N+1.  Why?  Because the creation of a *new* framework means that there is 
no existing code that uses it.  And if the framework only provides features 
that others already have, there's no compelling reason to switch.

Any approach that ignores the economic reality of present-day Python web 
apps, and provides no way for them to migrate gradually to a new standard, 
is doomed to niche status at best.  (Comparison to ASP and PHP is 
misleading: both had standards for dispatching, sessions, cookies, form 
parsing, and templating *when they were created*, so there was no legacy 
codebase using alternative solutions that had to be migrated.)

And so, the only way we're going to "steal" the marketshare of existing 
frameworks is with the consent and co-operation of the developers of those 
frameworks.  That means there has to be enough benefit for them to justify 
the effort of getting on board.

So, please allow me to reveal my top-secret plan for total world 
domination...  :)

First, the current situation.  Choice of framework is a high investment for 
users, because once they choose, they are stuck with that framework and 
possibly server.  The cost to switch is extremely high.  It's almost as 
though every plumbing manufacturer makes their own sizes of pipes and 
connectors, so once you choose a vendor, you're stuck with them.

WSGI changes this scenario by introducing competitive pressure to the 
server/framework choice.  As soon as enough framework and server developers 
participate, the others are pushed by network effects to do the 
same.  Users ask, "Why can't I use your framework in any WSGI server?" and 
"Why can't I use any WSGI framework in your server?", pushing the slower 
adopters to either join up or be marginalized.

But this is just the first phase: standardizing on a size for one kind of 
pipe.  It's not very glamorous, but it fundamentally changes the 
marketplace, and causes many things to appear to spontaneously happen "on 
their own".

First, users can experiment with other frameworks, especially if those 
frameworks are lightweight.  This builds competitive pressure in the 
direction of lightweight, easy-to-integrate frameworks.  So framework 
developers begin to break their monolithic approaches down into smaller 
pieces that operate on segments of WSGI.  For example, a session service 
that you pass the incoming 'environ' and outgoing 'headers' to, in order 
for it to read and set cookies.  (Notice that this *isn't* a WSGI-defined 
or standardized service, just a service implemented *in terms of* WSGI.)

Such a service makes little sense to implement today, but people will 
spontaneously begin developing such services once WSGI is a ubiquitous part 
of the Python web development landscape.  It's the most natural thing in 
the world for them to do so, not only because it means a wider audience for 
their service, but because they're likely developing it for a WSGI-based 
environment they're already using.  What other platform would they write it 
for?

Because these services will be interchangeable to some degree, lock-in is 
limited and competition will determine a winner or winners.  Then, if the 
winners are sufficiently similar to allow useful standardization, that's 
the natural next step.  But, for some services, the differences will be 
important qualitative differences, and standardization would reduce 
meaningful choice.  We don't know in advance what these services should be, 
and we don't know enough to standardize on them now.

For someone with an ASP or PHP background, that last statement at least 
might sound like sheer lunacy.  But, Python web frameworks have often 
pioneered techniques years ahead of their appearance in ASP, PHP, and Java 
frameworks.  I would hate for us to lose our next great innovation to 
premature standardization.

But luckily, I don't need to worry: there's simply no way you'll get enough 
Python framework developers (and their users) to agree on such a 
standardization.  For one thing, it's not in their best interests to do 
so.  (Don't let me discourage you from trying, though, if that's what you 
want to do.  I just don't think you'll have much success, and am not 
interested in trying it myself.)


Anyway, there it is.  My secret plan to fundamentally alter the Python web 
programming universe through secret mind-control market manipulation and 
social engineering.  You found me out.  Now I'll have to kill you.*  :)


* "And I'd have gotten away with it too, if it hadn't been for those 
meddling kids..."


(Disclaimer for non-US readers: the above is a humorous reference to an 
American TV cartoon that featured a different character saying this line 
each week, after their nefarious plans were foiled.  It's not me calling 
anybody a meddling kid, or threatening to actually kill anyone!)