[Web-SIG] Web Container Interface

[Greg Ward]

On 23 January 2004, Phillip J. Eby said:
> But there isn't any functionality the proposal requires of the container 
> beyond this.  For example, what would a plain CGI container provide?  A 
> FastCGI container?  For a lowest-common-denominator interface, what 
> "integration" is possible or needed?

[...stepping into this discussion a few days late...]

I spend a lot of time with the Java Servlet API at work these days, and
I think I have a pretty good handle on what's good about it and what's
not good.  Obviously, I think we should rip off the good ideas, and
leave the bad ones behind.

First of all, the absolute #1 best thing about the Java Servlet API is
that it provides a complete but simple object-oriented wrapper for HTTP
request-processing in the form of the HttpServletRequest and
HttpServletResponse classes.  (I can't say offhand if the wrapping is
100% perfectly complete, but I can say that it provides clean, simple
access to every feature of HTTP I need in my day-to-day work.)

(I'm fairly agnostic on the issue of whether these should be one class
or two.  The fact that no one has proposed a good name for the combined
request+response object is enough to put me in the "two objects" camp.
Also, I think I would prefer "response.set_header(...)" to
"thingy.set_response_header(...)".  But don't conflate my slight
preference here for my appreciation of Java's request/response classes!)

OTOH, the worst thing about the Java Servlet API is the notion of a
servlet.  There are two problems here:

  * premature overgeneralization; it looks like the servlet API was
    designed to allow people to someday write servlets for FTP
    servers or other as-yet-unknown protocols.  This is stupid;
    web applications use HTTP.  Period.

  * the level of granularity is wrong: most Java web applications
    consist of multiple servlets, and if the code I work on in my
    day job is any indication, there's a lot of overlapping code
    among the servlets in a given application.  Thus, the point
    of entry between a web application container and a collection
    of web applications should be... the web application.

    (The Java community has figured this out; when you administer a
    modern servlet container like Tomcat, you generally work at the
    level of web apps, rather than individual servlets or the whole
    container.  The existence of "servlets" as a separate entity
    complicates both administering a servlet container and writing web
    applications.  It's a nasty design flaw that we should strenuously
    avoid.)

The other thing that bugs me about the Java world is that their web
application containers -- Tomcat in particular, since that's the one I
use everyday -- are enormously complex, bloated beasts.  They're hard to
understand, hard to setup, and hard to administer.  They keep thousands
of people employed at banging their heads against confusing, arcane XML
config files.  (Come to think of it, the same could be said of Java web
development frameworks.)

My gut feeling is that a barebones web container -- say, one that
enables Quixote applications to run as FastCGI scripts, say -- should
fit into 10 lines of Python code.  A super-duper, whiz-bang,
all-singing, all-dancing container -- enable applications written under
N different frameworks to execute using M different models -- should fit
in roughly 1000 lines of Python.

One big challenge I can foresee: the Python community will never allow a
standard web container interface to mandate a particular execution
model, as the Java Servlet API does.  Writing a single API that handles
both Twisted/Medusa-style (event-driven I/O) and Java-style (threaded
I/O) will be difficult; it might be impossible.  (Hmmm, maybe there is a
third model: traditional Unix-style (multiprocess I/O).)  I would rather
see two (three?) related APIs than one really complicated API that tries
to cover all the bases.

Finally, in reponse to a later remark by Philip (I think): I definitely
like calling the things that web developers write "web applications".
"Web service" implies to me a special case of web application that does
not have a human user interface.  And I'm perfectly comfortable calling
the software that runs web applications an "application container".
"Application engine" and "application server" also make sense to me.
Whatever terminology we pick, it should be carefully defined in that
PEP!

        Greg
-- 
Greg Ward <gward at python.net>                         http://www.gerg.ca/
Heisenberg may have slept here.