[Web-SIG] Web Container Interface
Ian Bicking
ianb at colorstudy.com
Wed Jan 28 14:16:53 EST 2004
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
More information about the Web-SIG
mailing list