[Web-SIG] Regarding the WSGI draft

[Paul Boddie]

Bob Kimble wrote:
->
-> I have been reading this thread for a while now, and I haven't
commented 
-> because I have done absolutely no web development using Python.
However, 
-> Mark's comments strike me as being dead on. I'm used to the Java
Servlet
-> API, which creates an API for servlets and JSP pages. The fact that
there
-> are several high quality application servers that all support this
API
-> suggests to me that creating something similar for Python makes a lot
of
-> sense. I have written JSP's and servlets and run them under Tomcat,
but I
-> know that I could just as easily run them under WebSphere, WebLogic,
-> JRun, or any others that support the API.

Once the deployment gymnastics and library conflicts are dealt with,
yes.
;-) It's an interesting point that I'll hint at briefly below that it
isn't
exactly coincidence that the most popular Java frameworks are all based
on
the Servlet API in some way.

-> It seems to me that creating a similar API for Python would 
-> be terrific. Of course, somebody would also have to write an
application 
-> server to support the API, but I suspect some of the existing
frameworks 
-> could be revamped to support it. Anyway, that's my 2 cents. I would
love
-> to see something similar to Tomcat and the Java Servlet API for
Python.

Well, Webware was created with the Java Servlet API in mind, amongst
other
inspirations, and there are certainly plenty of frameworks which follow
the
same pattern. However, having looked into implementing the high-level
functionality that Mark Nottingham and Philip Eby are presumably
referring
to, and having looked into the differences between frameworks before
(which
led to the increasingly incoherent WebProgramming Wiki page), any future
work of mine in that area will be done on top of WebStack:

http://www.python.org/pypi?%3Aaction=search&name=WebStack

Clearly, by even mentioning it I'm pushing some kind of agenda, but
should I
want to develop some kind of Web application or framework, I'd rather
have a
reasonably sane API which works across the major technologies (and does
so
pretty well right now).

Titus Brown wrote:
>
> I'm moderately skeptical of the short term use of the API being
> developed on this list, because in practice it is relatively easy
> to implement a framework that fits on top of all of the existing
> adapters (CGI, mod_python, etc.)  Medium term, I think it will lead
> to a welcome homogenization of server <--> adapter <--> framework
> interaction, and so I think it's a valuable concept.

I think it depends how many frameworks you want to support and which
ones
you choose. The work may be intellectually straightforward, but it isn't
necessarily trivial. As for the value of the WSGI concept, if it
provides a
better foundation for higher-level frameworks and applications, then
it's
obviously a good thing. I'm not totally convinced that lots of people
might
want to run Webware on top of Twisted, for example, and that the Twisted
people will get excited by this very notion and do the work to make it
happen. (Although having now said that, they might rise to the
challenge.)
Moreover, when it comes to "co-locating" applications, there exists some
pretty adequate solutions for doing so right now through Apache and
other
generic Web server solutions.

> The idea of having a single framework (like Java's "servlets") is, I
> think, silly.  Having implemented sites in several of the existing
> frameworks, it is clear that there are several different ways to
> conceptualize the development of Web sites: the Quixote style and
> the WebWare style are two very distinct examples.  Anything that cuts
> down on the variety of available frameworks is going to restrict the
> options, which is bad.

There are a variety of Java frameworks which are based on the Servlet
API
and which offer a range of fairly diverse development styles. Few people
really want to code applications directly against that API, but it's
misleading (if not wrong) to state that a standard API at such a low
level
will somehow strongly constrain how you develop your applications.

As for the diversity of styles within Python Web frameworks, one has to
ask
whether such a standard API is useful and can support things like
Quixote,
SkunkWeb, Webware and Zope. If you split this analysis into the
dispatching
of requests and the request objects themselves, the area of "sensible"
diversity is the dispatching mechanism - where Python frameworks differ
in
their treatment of request and response information tends to be in how
comprehensive and consistent (or the opposite) the APIs for such
concepts
are. Where dispatching is concerned, I dislike the way many Python
frameworks decide on one's behalf how the URLs are going to be
interpreted,
and I welcome things like Ian Bicking's enhancements to Webware that
have
removed such inconveniences since 0.8.1; much diversity is arguably
arbitrary in this area, anyway.

> However, I think it is incumbent upon the developers and users of the
> different frameworks to clearly distinguish between the various
options.
> Right now it is very confusing to me, and I've been developing Web
sites
> in Python for 5 years ;).

The problem is that the average developer has to choose something to
start
out on, and having looked at most of the main frameworks I can say with
confidence that the average developer has to make a pretty big
compromise
between things like API sanity, API popularity and deployment
flexibility.
WSGI does its thing to make deployment less of an issue (along somewhat
with
API popularity), but avoids the burning issue of the standard API that
many
people within the Python frameworks scene insist isn't necessary whilst
also
hinting that it could be a good thing. Certainly, I'd regard a
discussion on
the need for such a thing as significantly more important than the
decorator
discussion at the very least.

Paul