[Web-SIG] Regarding the WSGI draft
paul.boddie at ementor.no
Fri Aug 27 12:32:58 CEST 2004
Bob Kimble wrote:
-> I have been reading this thread for a while now, and I haven't
-> because I have done absolutely no web development using Python.
-> Mark's comments strike me as being dead on. I'm used to the Java
-> API, which creates an API for servlets and JSP pages. The fact that
-> are several high quality application servers that all support this
-> suggests to me that creating something similar for Python makes a lot
-> sense. I have written JSP's and servlets and run them under Tomcat,
-> 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,
;-) It's an interesting point that I'll hint at briefly below that it
exactly coincidence that the most popular Java frameworks are all based
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
-> server to support the API, but I suspect some of the existing
-> could be revamped to support it. Anyway, that's my 2 cents. I would
-> to see something similar to Tomcat and the Java Servlet API for
Well, Webware was created with the Java Servlet API in mind, amongst
inspirations, and there are certainly plenty of frameworks which follow
same pattern. However, having looked into implementing the high-level
functionality that Mark Nottingham and Philip Eby are presumably
to, and having looked into the differences between frameworks before
led to the increasingly incoherent WebProgramming Wiki page), any future
work of mine in that area will be done on top of WebStack:
Clearly, by even mentioning it I'm pushing some kind of agenda, but
want to develop some kind of Web application or framework, I'd rather
reasonably sane API which works across the major technologies (and does
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
you choose. The work may be intellectually straightforward, but it isn't
necessarily trivial. As for the value of the WSGI concept, if it
better foundation for higher-level frameworks and applications, then
obviously a good thing. I'm not totally convinced that lots of people
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
Moreover, when it comes to "co-locating" applications, there exists some
pretty adequate solutions for doing so right now through Apache and
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
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
will somehow strongly constrain how you develop your applications.
As for the diversity of styles within Python Web frameworks, one has to
whether such a standard API is useful and can support things like
SkunkWeb, Webware and Zope. If you split this analysis into the
of requests and the request objects themselves, the area of "sensible"
diversity is the dispatching mechanism - where Python frameworks differ
their treatment of request and response information tends to be in how
comprehensive and consistent (or the opposite) the APIs for such
are. Where dispatching is concerned, I dislike the way many Python
frameworks decide on one's behalf how the URLs are going to be
and I welcome things like Ian Bicking's enhancements to Webware that
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
> Right now it is very confusing to me, and I've been developing Web
> in Python for 5 years ;).
The problem is that the average developer has to choose something to
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
between things like API sanity, API popularity and deployment
WSGI does its thing to make deployment less of an issue (along somewhat
API popularity), but avoids the burning issue of the standard API that
people within the Python frameworks scene insist isn't necessary whilst
hinting that it could be a good thing. Certainly, I'd regard a
the need for such a thing as significantly more important than the
discussion at the very least.
More information about the Web-SIG