tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Mon, 10 Jan 2000 15:11:30 GMT
Hans Bergsten wrote:

> > > Questions
> > > ---------
> > > A couple of questions that I have not seen any discussion about yet are:
> > >
> > > * Why are Request/Response representations of HttpServletRequest/Response
> > >   instead of ServletRequest/Response?
> > >
> >
> > It's based on my feeling that Tomcat is, first and foremost, an *HTTP* servlet
> > container.  Most of the design energy and features focus is around things that only
> > matter when the container knows the contents of the HTTP headers.
> >
> > It would be reasonable to build a servlet engine for non-interactive, non-HTTP-based
> > request/response stuff, but I don't see a lot of value add for doing this versus
> > alternative solutions based on RMI and/or CORBA APIs.
> 
> I was thinking about things like WebDAV, and possibly WAP. I imagine a server
> for these protocols may need other ServletRequest/Response subclasses than
> HttpServletRequest/Response.

Here comes the rain again... :)

Serious: this is the old story of Servlet API design mess. Good OO
practices indicate that when an object extends another, it inherits some
properties/functionalities and adds others.

For HTTPServlet request/response, this is _not_ the case.
HttpServletRequest is _not_ a servletRequest with some facility methods
for HTTP, or, at least, it has some very subdle and hidden design
limitations that makes really hard and "dirty" to come up with something
for other protocols.

Pier and I designed the MailServlet proposal that was rejected by James
last year. We didn't need to touch the API at all, they all were back
compatible, but the implementation would need to do a bunch of 

 if (request instanceof MailServletRequest) {
   ...
 }

as currently HttpServlet does. Which really sucks. Also, nobody is
actually having the energy to fight this and propose a "serious" and
"back compatible" design cleanup of the servlet API... and the mail
servlet idea (which I still find very cool) is resting in the JAMES
project, waiting for somebody to do something with it...

Anyway, you are thinking about WAP, but this doesn't matter. WAP is
designed not to require changes in the http servers. WAP gateways are
reponsible to provide WML encoding over digital wireless protocols to
reduce bandwith, but as far as we are concerned, a WAP request is
totally equivalent to an HTTP one (but, for example, for the user agent
or other header identifier)

WebDAV? same thing. WebDAV is a "blown up" HTTP. Sure, we could add a
WebDAVServlet, but that would extend HttpServlet in the real sense: it
adds functionality over HTTP, but doesn't require any change down below
in the middleware.

What else? RMI? better handled by the JVM. IIOP? better leave this to
real orbs. FTP? no way.

99% of the application-level internet trafic is 

  web (HTTP/HTTPS) + mail (SMTP/POP/IMAP) + news (NNTP)

Tomcat handles the first section. I propose to handle the second part
and I don't care about news.

Everything else is one layer up or one layer down, but, IMO, we should
not care about those in this project.
 
-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message