[Web-SIG] Regarding the WSGI draft

[Phillip J. Eby]

At 01:56 PM 8/27/04 +0100, Ben Sizer wrote:
>Phillip J. Eby wrote:
>>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,

Huh?  I meant niche status *within* the Python community.  My point is that 
trying to promote another framework isn't going to get much past the noise 
level in communicating about *current* frameworks.


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

Because if providing an alternative would actually change anything, then 
things should have already changed by now.  Simply providing a new 
framework will not create any technical or social network effects, so that 
leaves marketing as the  force to drive adoption.  And that marketing will 
be limited to either 1) new users, or 2) people you can get to switch from 
existing frameworks.


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

Okay, so you want to recruit non-Python developers; fine.  Go for 
it.  That's entirely orthogonal to what I'm trying to do with WSGI.  But, I 
think you'll have an easier time of it once WSGI is ubiquitous and APIs 
emerge that you can then use as a standard.


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

As a practical matter, you'll need commuity support to get something like 
that in the standard library, and the political reality of the community is 
that you'll have to show why accepting your new framework N+1 doesn't mean 
that frameworks 1 through N should also be included.


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

It's not that you should *need* one of them; it's merely that if adding 
such features gets in the way of WSGI goals, then we don't add such 
features.  And adding those features gets in the way of the goals if it 
adds unwarranted complexity to servers, gateways, or middleware.

Therefore, it may make sense for those wishing to devise a higher-level or 
"friendlier" API, to build it atop WSGI in parallel with the current 
standardization efforts, and then propose it as a stdlib addition once WSGI 
is stable and has seen some adoption, perhaps as part of an effort to 
upgrade the stdlib-included web servers and gateways to support WSGI.

Such efforts would be easier to spin as "tools for WSGI" rather than "web 
framework N+1".


>It sounds more like refusing to sell ready meals in stores because of
>the insistence that everybody likes their food cooked in different ways.

Not at all; we have dozens of lines of ready meals with names like 
Albatross, CherryPy, SkunkWeb, Quixote, and so on.  It's merely that the 
marketplace is already crowded with such manufacturers and launching a new 
line to compete with them isn't likely to be a profitable venture.

Instead, we've decided to standardize packaging materials and sell boxes 
and trays and suchlike to all the existing meal manufacturers.  :)


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

You must be making some assumptions that aren't clear to me.  If existing 
services provide 100% of those capabilities, why hasn't one of them already 
taken the lead?  Perhaps you think that endorsement by the Web-SIG is all 
that's needed.  Maybe that could work, I don't know.

But, how will you obtain the endorsement of the Web-SIG?  Keep in mind that 
a lot of the people actually doing any work on the Web-SIG are authors of 
existing frameworks, which means to get buy-in you have to support their 
goals.  To support their goals, you need an API that allows them to 
continue to scratch whatever itches prompted them to write their particular 
framework in the first place, not to mention avoid losing their investement 
in application code already written to that API.

But, the higher the level of abstraction in the API, the greater the chance 
that some facility on which they depend, will not be expressible in the 
high-level API so as to allow them to continue to use code based on their 
existing APIs, and therefore the more difficult it will be to get the 
support of those participants.

WSGI lets us bypass all this, by beginning with something that everybody 
can use, because everybody's using HTTP, and WSGI only deals with HTTP.


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

Fair enough.  But personally, if that were my goal, I'd design *two* APIs: 
one to emulate ASP, and the other to emulate PHP.  Then I'd write 
translators to do the mechanical work of translating most of the syntax to 
e.g. PSP.  That would do *much* more to bring in non-Python developers than 
any new Python framework would.  For one thing, the mere existence of such 
a tool for ASP or PHP applications would create vast amounts of publicity 
(blog postings, articles, etc.) that money couldn't buy, and they'd be in 
exactly the right places: where those non-Python programmers will see them.

By contrast, announcing another Python framework seems to me unlikely to 
create a splash even *within* the Python community, let alone outside it.