tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Mon, 10 Jan 2000 23:00:14 GMT
I'm all with Stefano that Servlets should focus on handling HTTP with
WAP/DAV as special cases that are well supported by the existing API.
RMI and IIOP do not belong here and there are already two models (ORB
and EJB) dealing with them in a better fashion.

I also would like to see SMTP support similar to the Servlet model, but
I don't think the two APIs exist in the same space or have enough
similarity. I think the JAMES design is very good, I'm questioning
whether it should be a Servlet API extension or a JavaMail API
extension. Perhaps the second one will be easier to pass through :-)


Stefano Mazzocchi wrote:
> 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
> > > 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.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message