[Web-SIG] Regarding the WSGI draft

[Ben Sizer]

Phillip J. Eby wrote:
> 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.

To quote http://www.python.org/sigs/web-sig/ again, "pick a Web
framework that already exists". To pick an example from my minimal
experience here, mod_python might make a good baseline because it's
reasonably low-level already and runs on Unix and Win32, yet provides
templating, dispatching, session handling, etc. Maybe if someone could
replicate a large subset of mod_python's functionality on IIS then you'd
have something very useful.

> 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.

I see your point but I look at this from the other side; any approach
that is focused on the current niche status of Python web apps, is
doomed to perpetuate that niche status. No new framework or API or
'standard' Python web service is going to break existing code, just
provide an alternative. Why therefore is there such a focus on
accommodating existing users and having them migrate over? This sounds
too much like preaching to the converted to me.

> 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.

I don't think the idea is to steal the marketshare of existing
frameworks, as you put it. Rather, I'd think it would be about apturing
the imagination of the average developer who would appreciate Python as
a language. Some people won't use ASP because of the Microsoft aspect,
or won't use PHP because of the Perl/C syntax. These are people who
would probably be very interested in using an open language such as
Python for this sort of thing.

> 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.

This is why I would like Python to have web support in the standard
library that is on a high enough level that you don't necessarily need a
framework to achieve something useful.

I readily agree that something such as WSGI would nicely form the
backbone of the interchangeable modules. All I disagree with that you
should then /need/ one of these competing frameworks on top of that
before you can do anything useful. Hence my worry about the insistence
on such frameworks. As it stands, web development is pretty much the
only commonplace task that I can't achieve with Python using either the
standard library or an obvious 3rd party package.

> 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.

It sounds more like refusing to sell ready meals in stores because of
the insistence that everybody likes their food cooked in different ways.
If we provided a simpler and effective baseline, even if that standard
only featured 90% of the power and flexibility of existing services,
then I expect we'd see a rapid take-up of that technology.

In no way do I think that the current services and frameworks are
useless. I just worry that there's this focus on what I'd vaguely call
'enterprise' level web development that shuts out the majority of
developers who are trying to do something simpler.

-- 
Ben Sizer.