[Web-SIG] Web Container Interface

[Ian Bicking]

Greg Ward wrote:
> 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 agree that a common request/response object(s) would be very useful, 
though stdout/stdin/environ encompasses all the same information, just 
in a crufty sort of way.  The advantage is really when you want to make 
portable libraries, like a form processor that needs access to the 
variables, but may occassionally want to look at the User-Agent header 
too (for dealing with DHTML compatibility issues).  I think people are 
being too pessimistic about it -- I don't see why it should be that hard 
to agree on a simple request/response object, with the expectation that 
current frameworks will wrap the object with different interfaces as 
necessary (or provide wrappers to make their objects look like the 
standard).

I don't think anything about WSGI (or whatever acronym we're going by ;) 
would preclude this.  Given such an interface, it would even be fairly 
simple to create a wrapper that creates the object given 
stdin/stdout/environ, then passes the call onto another object.  It 
would be a reasonable way to layer the two standards, without 
introducing any real inefficiency (well... depending on the way the 
applications are layered).

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

And it seems easier to translate FTP requests to HTTP requests than deal 
with the premature generalization.  Well, easy to translate it into 
objects -- I think it would be somewhat annoying to translate an FTP 
request into stdin/stdout/environ ;)

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

Can you expand?  Do you mean that servlets as an exposed resource are 
unnecessary, and that the only exposed resource should be the 
application as a whole?  Which may in turn be factored into servlets, 
but that's up to the application to determine...?

   Ian